[Bug translation/78745] Truncated messages in po file

[fmarchal at perso dot be]

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

--- Comment #2 from Frederic Marchal  ---
Same problem in gcc/config/bfin/bfin.opt at lines 56 and 69.

[Bug middle-end/78665] Unexpected warning about "assuming signed overflow does not occur when simplifying conditional"

[rjones at redhat dot com]

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

--- Comment #4 from Richard W.M. Jones  ---
Created attachment 40363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40363&action=edit
handle.i

Preprocessed source.  The full command to produce this was:

gcc -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib -I. -W -Wabi
-Waddress -Waggressive-loop-optimizations -Wall -Wattributes
-Wbad-function-cast -Wbool-compare -Wbuiltin-macro-redefined -Wcast-align
-Wchar-subscripts -Wchkp -Wclobbered -Wcomment -Wcomments -Wcoverage-mismatch
-Wcpp -Wdate-time -Wdeprecated -Wdeprecated-declarations -Wdesignated-init
-Wdisabled-optimization -Wdiscarded-array-qualifiers -Wdiscarded-qualifiers
-Wdiv-by-zero -Wdouble-promotion -Wempty-body -Wendif-labels -Wenum-compare
-Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-nonliteral
-Wformat-security -Wformat-signedness -Wformat-y2k -Wformat-zero-length
-Wfree-nonheap-object -Wignored-qualifiers -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wincompatible-pointer-types
-Winit-self -Winline -Wint-conversion -Wint-to-pointer-cast
-Winvalid-memory-model -Winvalid-pch -Wlogical-not-parentheses -Wlogical-op
-Wmain -Wmaybe-uninitialized -Wmemset-transposed-args -Wmissing-braces
-Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs
-Wmissing-parameter-type -Wmissing-prototypes -Wmultichar -Wnarrowing
-Wnested-externs -Wnonnull -Wodr -Wold-style-declaration -Wold-style-definition
-Wopenmp-simd -Woverflow -Woverlength-strings -Woverride-init
-Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-sign
-Wpointer-to-int-cast -Wpragmas -Wreturn-local-addr -Wreturn-type
-Wsequence-point -Wshadow -Wshift-count-negative -Wshift-count-overflow
-Wsizeof-array-argument -Wsizeof-pointer-memaccess -Wstack-protector
-Wstrict-aliasing -Wstrict-overflow -Wstrict-prototypes
-Wsuggest-attribute=const -Wsuggest-attribute=format
-Wsuggest-attribute=noreturn -Wsuggest-final-methods -Wsuggest-final-types
-Wswitch -Wswitch-bool -Wswitch-default -Wsync-nand -Wtrampolines -Wtrigraphs
-Wtype-limits -Wuninitialized -Wunknown-pragmas -Wunsafe-loop-optimizations
-Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function
-Wunused-label -Wunused-local-typedefs -Wunused-macros -Wunused-parameter
-Wunused-result -Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros
-Wvector-operation-performance -Wvolatile-register-var -Wwrite-strings
-Warray-bounds=2 -Wnormalized=nfc -Wno-unused-parameter
-Wno-missing-field-initializers -Wno-logical-op -Wno-array-bounds
-fdiagnostics-show-option -Werror -g -O2 -MT libhivex_la-handle.lo -MD -MP -MF
.deps/libhivex_la-handle.Tpo -c handle.c  -fPIC -DPIC -o
.libs/libhivex_la-handle.o -save-temps

[Bug target/78853] aligned reads/writes (vmovdqa) emitted when no such guarantee can be made

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Please run your code with -fsanitize=undefined before opening bugs in the
future.
See PR65709 for an explanation.

[Bug target/78855] -mtune=generic should keep cmp/jcc together. AMD and Intel both macro-fuse

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-19
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
(In reply to Peter Cordes from comment #0)

> The penalty for doing the compare a couple instructions later on CPUs that
> don't support fusion might increasing the mispredict penalty by a couple
> cycles, I think.  So I don't think we'd be hurting Atom a lot to help more
> common CPUs a little.

We do have FIXMEs to enable X86_TUNE_FUSE_CMP_AND_BRANCH for generic (and
intel) tunes.  But the default for generic won't be changed until there are
benchmark results that confirm your suggestions.

[Bug tree-optimization/78608] [7 Regression] gimple-ssa-sprintf.c:570:17: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
You should use abs_uhwi to simplify the code, it will be more readable then
conditionals with explanation comments why do you do that.

[Bug tree-optimization/78856] [6/7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-19
 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
   Target Milestone|--- |6.3
Summary|wrong code at -O3 on|[6/7 Regression] wrong code
   |x86_64-linux-gnu (in both   |at -O3 on x86_64-linux-gnu
   |32-bit and 64-bit modes)|(in both 32-bit and 64-bit
   ||modes)
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r232897.

[Bug target/78857] New: S390: Do not use load-and-test floating-point instruction to compare against 0.0 as SNaN is converted to QNaN.

[stli at linux dot vnet.ibm.com]

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

Bug ID: 78857
   Summary: S390: Do not use load-and-test floating-point
instruction to compare against 0.0 as SNaN is
converted to QNaN.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stli at linux dot vnet.ibm.com
  Target Milestone: ---
Target: S390

On s390, a comparison of e.g. a double value against 0.0 is done with ltdbr 
(load and test long BFP) instruction. If the value is a SNaN, this instruction
converts it to QNaN. This differs to a comparison with cdbr (compare long BFP)
instruction, which keeps the SNaN.
Thus, the usage of load-and-test instruction is not allowed, if the value in
the resulting register is used afterwards.

As information:
This leads to glibc "math/test-double" / "math/test-idouble" test failures
where pow is called with x=1.0 and y=SNaN.
The pow function performs a test against zero and y is later used to determine
the return value:
...
if (y == 0)
  return 1.0;
...
if (...)
  return x == 1.0 && !issignaling (y) ? 1.0 : y + y;
...

[Bug c++/78852] [7 Regression] ICE with Boost.Variant 1.62

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Summary|ICE with Boost.Variant 1.62 |[7 Regression] ICE with
   ||Boost.Variant 1.62

--- Comment #2 from Markus Trippelsdorf  ---
The small testcase started to ICE with r241843:

commit 6e1e09d49b0fd596a0654f56dd35e2f36802a31b
Author: jason 
Date:   Fri Nov 4 12:47:01 2016 +

PR c++/78198 - inherited template ctor with default arg

[Bug target/78748] [7 Regression] ICE in extract_insn, at recog.c:2311 (s390x-linux-gnu)

[krebbel at gcc dot gnu.org]

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

--- Comment #6 from Andreas Krebbel  ---
Author: krebbel
Date: Mon Dec 19 09:53:56 2016
New Revision: 243793

URL: https://gcc.gnu.org/viewcvs?rev=243793&root=gcc&view=rev
Log:
PR target/78748: S/390: Fix ICE with ANDC splitter.

gcc/ChangeLog:

2016-12-19  Dominik Vogt  

PR target/78748
* config/s390/s390.md ("*andc_split_"): Allow memory destination
only if it coincides with operand 2.

gcc/testsuite/ChangeLog:

2016-12-19  Dominik Vogt  

PR target/78748
* gcc.c-torture/compile/pr78748.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr78748.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog

[Bug target/78748] [7 Regression] ICE in extract_insn, at recog.c:2311 (s390x-linux-gnu)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/78567] [7 Regression] GCC trunk fails to compile all-stage2-gcc in i386.c with x32 enabled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
I believe this has been fixed with r242752, the fcn var is now unconditionally
initialized, so the warning you mention is not really possible.

[Bug fortran/78545] Possible correction to online LTIME documentation

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Dec 19 10:26:04 2016
New Revision: 243794

URL: https://gcc.gnu.org/viewcvs?rev=243794&root=gcc&view=rev
Log:
2016-12-19  Janus Weil  

PR fortran/78545
* intrinsic.texi: Minor documentation fixes for non-standard
time-related intrinsics. Add references to standard intrinsics and
linkify some existing references.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi

[Bug fortran/78545] Possible correction to online LTIME documentation

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|unknown |7.0
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #8 from janus at gcc dot gnu.org ---
Fixed with the above two commits. Closing.

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
I'm afraid I have too little knowledge of the I/O parts of libgfortran to fix,
but I can at least give some pointers to where things appear to go wrong ...

In the function "nml_write_obj" at line 2210 of write.c there is a block
starting with:


  if (obj->dtio_sub != NULL)
{
  int unit = dtp->u.p.current_unit->unit_number;


This whole block deals with calling DTIO procedures. Apparently the line above
that sets the unit is not enough to deal with internal units.

It seems that there is some code to deal with internal units e.g. in the
function "write_block" in transfer.c:

  if (is_internal_unit (dtp))
...

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-19
 Ever confirmed|0   |1

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

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Another starting point could be the fact that DTIO procedures appear to work
well on internal units, as long as no namelist output is involved. This case
seems to be handled by "formatted_transfer_scalar_write"?

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from vehre at gcc dot gnu.org ---
Closing.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #40357|0   |1
is obsolete||

--- Comment #18 from janus at gcc dot gnu.org ---
Created attachment 40364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40364&action=edit
updated patch

Here is an updated patch, which fixes all wrong-code issues AFAICS. It includes
improved handling of CLASS-vs-TYPE variables (analogous to PR 78848) and a
full-featured test case (which currently fails due to PR 78854).

Note that the patch does not handle the rejects-valid problem of comment 5
(which rather belong into PR 78659).

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|diagnostic  |
   Target Milestone|--- |7.0

[Bug tree-optimization/71854] [7 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple failed)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2016-07-13 00:00:00 |2016-12-19
 CC||aldyh at gcc dot gnu.org

--- Comment #4 from Aldy Hernandez  ---
This bug is no longer reproducible on mainline, with the above options, after
this patch:

commit b0c413f240ec2431c4a93d86f87e66a57bc5d51e   
Author: wschmidt   
Date:   Thu Nov 17 14:22:17 2016 +

[gcc]

2016-11-17  Bill Schmidt  
Richard Biener   
PR tree-optimization/77848
* tree-if-conv.c (tree_if_conversion): Always version loops unless
the user specified -ftree-loop-if-convert.

In order to continue reproducing you must now use:

-O3 -ftree-loop-if-convert

[Bug target/78567] [7 Regression] GCC trunk fails to compile all-stage2-gcc in i386.c with x32 enabled

[marc.mutz at kdab dot com]

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

Marc Mutz  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #4 from Marc Mutz  ---
I can confirm this is fixed in trunk now. Thanks!

[Bug libstdc++/78830] std::prev accepts ForwardIterator-s

[akrzemi1 at gmail dot com]

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

--- Comment #4 from Andrzej Krzemienski  ---
Just to clarify, what I request for this "unconditional" check is not the
existence of all operators, but only the check for the iterator_tag (we expect
a bidirectional iterator).

That is, the problem that I believe needs immediate solution is not improving
the error messages a la concepts, but preventing the current situation where
GCC assumes that the iterator passed to prev() is at least
BidirectionalIterator, and based on this assumption it tag-dispatches the call
to advance() overload for ForwardIterators, where it calls operator++.

[Bug c++/78858] New: Bogus -Wnonnull warning involving strcmp.

[marc.mutz at kdab dot com]

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

Bug ID: 78858
   Summary: Bogus -Wnonnull warning involving strcmp.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Latest trunk emits spurious -Wnonnull warnings, eg. in Qt:

  qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp: In member function ‘void
QCoreApplicationPrivate::processCommandLineArguments()’:
  qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp:195:20: error: argument 1
null where non-null expected [-Werror=nonnull]
   if (strncmp(arg, "-qmljsdebugger=", 15) == 0) {
   ~~~^~~~

The surrounding code reads:

   int j = argc ? 1 : 0;
   for (int i = 1; i < argc; ++i) {
   if (!argv[i])
   continue;
   if (*argv[i] != '-') {
   argv[j++] = argv[i];
   continue;
   }
   const char *arg = argv[i];
   if (arg[1] == '-') // startsWith("--")
   ++arg;
   if (strncmp(arg, "-qmljsdebugger=", 15) == 0) {
   qmljs_debug_arguments = QString::fromLocal8Bit(arg + 15);

where argc and argv are member variables (of types int and char**, resp.).

This warning is bogus for two reasons: First, we deref 'arg' in the preceding
if-statements. If it was nullptr, then that would invoke UB, so the compiler
can assume that arg is non-null. Second, we explicitly check for a nullptr
'arg' as the first thing in the loop, and we call no functions in-between that
could change the state. We also don't do perform any atomic operations.

This is not an isolated error. GCC creates dozens of warnings in Qt code, but
most of them are not as clearly wrong as this one.

This one I cannot even fix by moving the arg definition to the first line of
the loop and checking for !arg in the first if:


const char *arg = argv[i];
if (!arg)
continue;

[Bug c++/78858] Bogus -Wnonnull warning involving strcmp.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-19
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please attach self-contained test-case (either created by -E) or by
modifying mine, which does not show the problem:

#include 
#include 

void foo (const char *a);

struct A
{
  int
  main (void)
  {
int j = argc ? 1 : 0;
for (int i = 1; i < argc; ++i)
  {
if (!argv[i])
  continue;
if (*argv[i] != '-')
  {
argv[j++] = argv[i];
continue;
  }
const char *arg = argv[i];
if (arg[1] == '-') // startsWith("--")
  ++arg;
if (__builtin_strncmp (arg, "-qmljsdebugger=", 15) == 0)
  foo (arg + 15);
  }
  }

  int argc;
  char **argv;
};

int
main ()
{
  A a;
  a.main ();
}

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||pmderodat at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
So, first of all, it seems gdb handles this as expected no matter if it is the
debug info emitted by GCC 5 or 6+.  Say for protocol field,
data_member_location is either 0 and bit_offset 16, or data_member_location 1
and bit_offset 24 and the type is unsigned int in each case and little endian. 
So it is either bits 16-24 in unsigned int starting at offset 0, or bits 24-32
at unsigned int starting at offset 1, that is the same thing.  So the question
is why does it matter to you?
Though, I'd think it might be nicer to use byte_position of
DECL_BIT_FIELD_REPRESENTATIVE as data_member_location (so data_member_location
0 in this case).

[Bug tree-optimization/71854] [7 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/78847] pointer arithmetic from c++ ranged-based for loop not optimized

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-19
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Marc Glisse  ---
Not sure what the best angle is here.

_18 = (unsigned long) &MEM[(void *)&foo + 9B];
_16 = _18 + 1;

looks like it would be better as:

_19 = (unsigned long) &foo;
_16 = _19 + 10;

(I guess we don't want to produce &MEM[(void *)&foo + 10B])

But that might not be true anymore if _18 had several uses.

Reassoc could also play a role, either to cancel the two +1, or to put the two
converted addresses together.

I guess extra match.pd patterns might be doable as well, but I am scared of the
number of variants that might appear.

[Bug debug/65821] [5/6/7 regression] incorrect debug line # info for main

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
The default arguments are evaluated in the caller even for non-inline
functions, for those we can hardly have any DW_AT_inline or
DW_TAG_inlined_subroutine just because of the arguments.
So, the question is, do we want for the debug experience have the location info
of the default parameters come from the location where the expression of the
default parameters appear in the source (that is what current gcc emits), or do
we want it to be overridden to the call location (that is pretty much what we
used to emit before)?

[Bug bootstrap/78859] New: profiledbootstrap failure caused by -Werror=nonnull

[marxin at gcc dot gnu.org]

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

Bug ID: 78859
   Summary: profiledbootstrap failure caused by -Werror=nonnull
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

There are 2 (so far) errors reported:

1) gengtype.c:

../../gcc/gengtype.c: In function ‘const char*
get_file_srcdir_relative_path(const input_file*)’:
../../gcc/gengtype.c:1760:14: error: argument 1 null where non-null expected
[-Werror=nonnull]
   if (strlen (f) > srcdir_len
   ~~~^~~

This is real bug, following patch fixes that:

diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index dcc2ff5c358..138bb7c6588 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -1757,7 +1757,8 @@ const char *
 get_file_srcdir_relative_path (const input_file *inpf)
 {
   const char *f = get_input_file_name (inpf);
-  if (strlen (f) > srcdir_len
+  if (f != NULL
+  && strlen (f) > srcdir_len
   && IS_DIR_SEPARATOR (f[srcdir_len])
   && strncmp (f, srcdir, srcdir_len) == 0)
 return f + srcdir_len + 1;

2) c-format.c 

cc1plus: error: argument 1 null where non-null expected [-Werror=nonnull]
In file included from
/home/marxin/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/cstring:42:0,
 from ../../gcc/system.h:235,
 from ../../gcc/c-family/c-format.c:21:
/usr/include/string.h:394:15: note: in a call to function ‘size_t strlen(const
char*)’ declared here
 extern size_t strlen (const char *__s)
   ^~

It's more interesting as it's not real bug and will be probably similar to
PR78858:

133t.pre pass does:

   [0.00%]:
  _261 = strlen (0B);
  _46 = (int) _261;

   [19.09%]:
  # _138 = PHI <0B(98), _78(144), _108(116), _108(132), _8(131), _108(123),
p_21(99)>
  # prephitmp_211 = PHI <_46(98), iftmp.97_91(144), prephitmp_235(116),
prephitmp_235(132), iftmp.97_142(131), prephitmp_235(123), _51(99)>
  format_types.300_56 = format_types;

where the only edge to 98 is:
  # DEBUG attr_name => p_21
  if (p_21 == 0B)
goto ; [0.00%]
  else
goto ; [100.00%]


from:

   [0.00%]:

   [19.09%]:
  # _138 = PHI <0B(98), _78(144), _108(116), _108(132), _8(131), _108(123),
p_21(99)>
  # DEBUG attr_name => NULL
  # DEBUG i => NULL
  # DEBUG s => NULL
  _52 = strlen (_138);
  format_types.300_56 = format_types;

I'm attaching tree dumps of 131.crited1 and 133.pre

[Bug bootstrap/78859] profiledbootstrap failure caused by -Werror=nonnull

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 40365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40365&action=edit
131.crited1 dump

[Bug c++/78858] Bogus -Wnonnull warning involving strcmp.

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
Created attachment 40366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40366&action=edit
Preprocessed source

Command line used:

  g++ -E -pipe -ffunction-sections -O2 -g -fPIC -std=c++1z -fno-exceptions
-fsanitize=address -fsanitize=undefined -fno-omit-frame-pointer -Wall -W -Wvla
-Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Werror -Wno-error=cpp
-Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT
-DQT_VERSION_STR='"5.8.0"' -DQT_VERSION_MAJOR=5 -DQT_VERSION_MINOR=8
-DQT_VERSION_PATCH=0 -DQT_BOOTSTRAPPED -DQT_LITE_UNICODE -DQT_NO_CAST_TO_ASCII
-DQT_NO_CODECS -DQT_NO_DATASTREAM -DQT_NO_LIBRARY -DQT_NO_QOBJECT
-DQT_NO_SYSTEMLOCALE -DQT_NO_THREAD -DQT_NO_UNICODETABLES
-DQT_NO_USING_NAMESPACE -DQT_NO_DEPRECATED -DQT_NO_TRANSLATION
-DQT_CRYPTOGRAPHICHASH_ONLY_SHA1 -DQT_NO_FOREACH -DQT_NO_CAST_FROM_ASCII
-DQT_BUILD_BOOTSTRAP_LIB -DQT_BUILDING_QT -DQT_ASCII_CAST_WARNINGS
-DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/marc/Qt/qt5/qtbase/src/tools/bootstrap -I. -I../../../include
-I../../../include/QtCore -I../../../include/QtCore/5.8.0
-I../../../include/QtCore/5.8.0/QtCore -I../../../include/QtXml
-I../../../include/QtXml/5.8.0 -I../../../include/QtXml/5.8.0/QtXml
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ -o qcoreapplication.ii
/home/marc/Qt/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp

[Bug middle-end/30908] tree cost for types which are > WORD_SIZE

[saaadhu at gcc dot gnu.org]

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

Senthil Kumar Selvaraj  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #22 from Senthil Kumar Selvaraj  ---
This basically boils down to inconsistent estimated size cost to actual code
size ratio.
Without a -mmcu, the arch defaults to avr2, which supports only rcall. The
(hard coded) call cost size is 2, and rcall is 2 bytes long - the ratio of
estimated size cost to actual size is 1.

The (const propagated) wait function's size cost estimate is 6 (3 if inlined),
whereas the actual code code size is 12. The ratio is totally off now i.e. 2
instead of the 1 calculated for the call cost.

The wild variation in ratio makes ipa-inline is the root cause for the
inlining. For the first inline call, removing the call reduces cost by 2, and
plugging in the inline code increases it by 3, for an effective size cost
increase of 1. 

With the second inline call though, the callee can be eliminated, and the
calculated size cost is + 1 - 6 = -5. The total estimated size cost -5 + 1 = -4
i.e. smaller than the non-inlined case, and so ipa-inline decides to inline the
two calls.

[Bug bootstrap/78859] profiledbootstrap failure caused by -Werror=nonnull

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 40367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40367&action=edit
133.pre dump

[Bug c++/78858] Bogus -Wnonnull warning involving strcmp.

[marc.mutz at kdab dot com]

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

--- Comment #3 from Marc Mutz  ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
gcc version 7.0.0 20161219 (experimental) (GCC)

[Bug c++/78858] [7 Regression] Bogus -Wnonnull warning involving strcmp with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Target Milestone|--- |7.0
Summary|Bogus -Wnonnull warning |[7 Regression] Bogus
   |involving strcmp.   |-Wnonnull warning involving
   ||strcmp with
   ||-fsanitize=undefined

--- Comment #4 from Jakub Jelinek  ---
Ah, -fsanitize=undefined; -Wnonnull is right now broken with this option, see
http://gcc.gnu.org/ml/gcc-patches/2016-12/msg01547.html
http://gcc.gnu.org/ml/gcc-patches/2016-12/msg01550.html
http://gcc.gnu.org/ml/gcc-patches/2016-12/msg01571.html

[Bug c++/78858] [7 Regression] Bogus -Wnonnull warning involving strcmp with -fsanitize=undefined

[marc.mutz at kdab dot com]

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

--- Comment #5 from Marc Mutz  ---
Created attachment 40368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40368&action=edit
Another TU that has an unfixable -Wnonnull warning

g++ -c -pipe -ffunction-sections -O2 -g -fPIC -std=c++1z -fno-exceptions
-fsanitize=address -fsanitize=undefined -fno-omit-frame-pointer -Wall -W -Wvla
-Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Werror -Wno-error=cpp
-Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT
-DQT_VERSION_STR='"5.8.0"' -DQT_VERSION_MAJOR=5 -DQT_VERSION_MINOR=8
-DQT_VERSION_PATCH=0 -DQT_BOOTSTRAPPED -DQT_LITE_UNICODE -DQT_NO_CAST_TO_ASCII
-DQT_NO_CODECS -DQT_NO_DATASTREAM -DQT_NO_LIBRARY -DQT_NO_QOBJECT
-DQT_NO_SYSTEMLOCALE -DQT_NO_THREAD -DQT_NO_UNICODETABLES
-DQT_NO_USING_NAMESPACE -DQT_NO_DEPRECATED -DQT_NO_TRANSLATION
-DQT_CRYPTOGRAPHICHASH_ONLY_SHA1 -DQT_NO_FOREACH -DQT_NO_CAST_FROM_ASCII
-DQT_BUILD_BOOTSTRAP_LIB -DQT_BUILDING_QT -DQT_ASCII_CAST_WARNINGS
-DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/marc/Qt/qt5/qtbase/src/tools/bootstrap -I. -I../../../include
-I../../../include/QtCore -I../../../include/QtCore/5.8.0
-I../../../include/QtCore/5.8.0/QtCore -I../../../include/QtXml
-I../../../include/QtXml/5.8.0 -I../../../include/QtXml/5.8.0/QtXml
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ -o .obj/qjsonparser.o
/home/marc/Qt/qt5/qtbase/src/corelib/json/qjsonparser.cpp
In file included from ../../../include/QtCore/qvector.h:1:0,
 from
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/io/qdebug.h:51,
 from ../../../include/QtCore/qdebug.h:1,
 from
/home/marc/Qt/qt5/qtbase/src/corelib/json/qjsonparser.cpp:44:
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qvector.h: In
member function ‘void QJsonPrivate::Parser::ParsedObject::insert(uint)’:
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qvector.h:717:13:
error: argument 2 null where non-null expected [-Werror=nonnull]
 memmove(i, b, (d->size - offset) * sizeof(T));
 ^~~

[Bug c++/78858] [7 Regression] Bogus -Wnonnull warning involving strcmp with -fsanitize=undefined

[marc.mutz at kdab dot com]

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

--- Comment #6 from Marc Mutz  ---
Ah, I see.

[Bug target/78860] New: ICE in compilation for MIPS with -mpaired-single

[niva at niisi dot msk.ru]

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

Bug ID: 78860
   Summary: ICE in compilation for MIPS with -mpaired-single
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niva at niisi dot msk.ru
  Target Milestone: ---

The source file is:
---
typedef unsigned char uint8_t;
typedef float v2sf __attribute__ ((vector_size (8)));

uint8_t _simple_testV2SF (v2sf *pv)
{
  const v2sf val = *pv;
  const uint8_t *val8 = (uint8_t *)&val;
  return val8[0];
}

The compiler used was gcc-4.9.4 configured for mips:

Target: mips64-none-elf
Configured with: /home/niva/src/gcc-4.9.4/configure --target=mips64-none-elf
--enable-threads=no --disable-shared --enable-long-long --enable-c99
--enable-languages=c,c++,fortran --enable-multilib --enable-symvers=gnu
--disable-libmudflap --disable-libssp --disable-libgcc_eh
--disable-libstdc++-v3 --disable-libgfortran --with-newlib --with-dwarf2
--with-system-zlib --without-cloog --enable-generated-files-in-srcdir --verbose
--prefix=/home/niva/local --enable-cpp

The following command line results in internal compiler error:
--
LANG=C mips64-none-elf-gcc -O1 -mips64 -mpaired-single -S tstV2SF.c 2>err

(The output is attached.)

[Bug target/78860] ICE in compilation for MIPS with -mpaired-single

[niva at niisi dot msk.ru]

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

niva at niisi dot msk.ru changed:

   What|Removed |Added

 Target||MIPS
 CC||niva at niisi dot msk.ru

--- Comment #1 from niva at niisi dot msk.ru ---
The error was also reproduced with gcc-4.7.4 (similar configuration).

The test is successfully compiled with gcc-7.0.0 (similar configuration).

[Bug bootstrap/78859] profiledbootstrap failure caused by -Werror=nonnull

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #0)
> There are 2 (so far) errors reported:
> 
> 1) gengtype.c:
> 
> ../../gcc/gengtype.c: In function ‘const char*
> get_file_srcdir_relative_path(const input_file*)’:
> ../../gcc/gengtype.c:1760:14: error: argument 1 null where non-null expected
> [-Werror=nonnull]
>if (strlen (f) > srcdir_len
>~~~^~~
> 
> This is real bug, following patch fixes that:

Only iff get_file_srcdir_relative_path is ever called with NULL inpf.  If not,
it is a false positive.  As strlen would crash if it is called with NULL and it
has not been reported yet, it clearly is not.

[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11

[vz-gcc at zeitlins dot org]

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

--- Comment #4 from Vadim Zeitlin  ---
Thanks for the explanation! I didn't realize the template function below was
smart enough to select __builtin_powil() automatically, this is quite
impressive (although it doesn't happen in my particular case...). Also, I
thought the comment was temporary because of the question in it: "What should
the return type of pow(float,int) be?", which seemed to require an answer
("double"), but maybe it's just a figure of style I didn't understand.

In practice, I definitely do not want to use -ffast-math (if anything, I'd
rather use -fexcess-precision=standard but it's, unfortunately, not available
for C++). And I can't change my (well, MinGW-w64's) libm. So, again, in this
particular case, if I understand you correctly, it seems like I simply will
have to live with the (very small, admittedly) loss of precision after
migrating the existing code base from C++98 to C++11, right?

And, to finish, yes, I did see the calculation being inlined when using
-fwhole-program or -flto (although the "assembly" output of the latter is a bit
more difficult to examine) and it happened even in much less trivial examples
and I was duly impressed by it (no kidding). However it still doesn't (and
can't) happen in my real code which is a bit more complicated.

[Bug c++/78861] New: sequencer.cpp:603:53: error: cannot convert 'std::basic_istream::__istream_type {aka std::basic_istream}' to 'bool' in assignment

[martin.gansser at gmail dot com]

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

Bug ID: 78861
   Summary: sequencer.cpp:603:53: error: cannot convert
'std::basic_istream::__istream_type {aka
std::basic_istream}' to 'bool' in assignment
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin.gansser at gmail dot com
  Target Milestone: ---

Hi,

i tried to compile a programm with gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2),
but this fails with this error message:

cd
/home/martin/rpmbuild/BUILD/plee-the-bear-0.7.0-light/plee-the-bear/lib/src/ptb
&& /usr/bin/c++   -DNDEBUG -DPTB_TEXT_DOMAIN_PATH=/usr/share/locale
-Dplee_the_bear_EXPORTS -I/usr/include/SDL
-I/usr/include/bear/bear-engine/core/src
-I/usr/include/bear/bear-engine/lib/src
-I/home/martin/rpmbuild/BUILD/plee-the-bear-0.7.0-light/plee-the-bear/lib/src/ptb/..
 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64
-mtune=generic  -DNDEBUG -fPIC   -Wall -std=c++11 -pedantic
-Wmissing-field-initializers -Wuninitialized -o
CMakeFiles/plee_the_bear.dir/item/mini-game/code/sequencer_control.cpp.o -c
/home/martin/rpmbuild/BUILD/plee-the-bear-0.7.0-light/plee-the-bear/lib/src/ptb/item/mini-game/code/sequencer_control.cpp
/home/martin/rpmbuild/BUILD/plee-the-bear-0.7.0-light/plee-the-bear/lib/src/ptb/item/mini-game/code/sequencer.cpp:
In member function 'bool ptb::sequencer::load_track_file(const string&)':
/home/martin/rpmbuild/BUILD/plee-the-bear-0.7.0-light/plee-the-bear/lib/src/ptb/item/mini-game/code/sequencer.cpp:603:53:
error: cannot convert 'std::basic_istream::__istream_type {aka
std::basic_istream}' to 'bool' in assignment
 result = ( iss >> t.duration >> t.width );


In the relevant source file:

bool ptb::sequencer::load_track_file( const std::string& file_name )
{
  std::stringstream f;
  bear::engine::resource_pool::get_instance().get_file(file_name, f);
  std::string line;
  track t;
  bool result(false);
  bear::universe::time_type prev_date(0);
  std::size_t n(0);

  while ( !result && std::getline(f, line) )
{
  claw::text::trim(line);

  if ( !line.empty() )
if ( line[0] != '#' )
  {
std::istringstream iss(line);
result = ( iss >> t.duration >> t.width );
  }

  ++n;
}

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[paul.richard.thomas at gmail dot com]

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

--- Comment #5 from paul.richard.thomas at gmail dot com  ---
Hi Janus,

Jerry is the expert here.

Cheers

Paul

On 19 December 2016 at 11:59, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
>
> --- Comment #4 from janus at gcc dot gnu.org ---
> Another starting point could be the fact that DTIO procedures appear to work
> well on internal units, as long as no namelist output is involved. This case
> seems to be handled by "formatted_transfer_scalar_write"?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug bootstrap/78859] profiledbootstrap failure caused by -Werror=nonnull

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Martin Liška from comment #0)
> > There are 2 (so far) errors reported:
> > 
> > 1) gengtype.c:
> > 
> > ../../gcc/gengtype.c: In function ‘const char*
> > get_file_srcdir_relative_path(const input_file*)’:
> > ../../gcc/gengtype.c:1760:14: error: argument 1 null where non-null expected
> > [-Werror=nonnull]
> >if (strlen (f) > srcdir_len
> >~~~^~~
> > 
> > This is real bug, following patch fixes that:
> 
> Only iff get_file_srcdir_relative_path is ever called with NULL inpf.  If
> not, it is a false positive.  As strlen would crash if it is called with
> NULL and it has not been reported yet, it clearly is not.

So with the following patch (and -disable-werror) the profiledbootstrap
finishes:

@@ -75,9 +75,8 @@ const char *get_file_srcdir_relative_path (const input_file
*inpf);
 static inline const char*
 get_input_file_name (const input_file *inpf)
 {
-  if (inpf)
-  return inpf->inpname;
-  return NULL;
+  gcc_assert (inpf);
+  return inpf->inpname;
 }

Thus, it's regression.

[Bug c++/78861] sequencer.cpp:603:53: error: cannot convert 'std::basic_istream::__istream_type {aka std::basic_istream}' to 'bool' in assignment

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
https://gcc.gnu.org/gcc-6/porting_to.html

gcc-bugs@gcc.gnu.org

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #22 from Bernd Schmidt  ---
Ok, so I have a patch that makes the original testcase pass, by allowing
folding in get_unwidened depening on a new arg. That was:

unsigned char p;
unsigned char p1 = p & 512;

But, how about

char p2 = p & 512;

Are we supposed to still warn about this (we do, with the patch I have)?
Probably not, right?

[Bug target/78853] aligned reads/writes (vmovdqa) emitted when no such guarantee can be made

[gonnet at google dot com]

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

--- Comment #3 from Pedro Gonnet  ---
OK, thanks for clarifying!

The declaration of __m256i only specifies the attributes vector_size and
may_alias
(https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/avxintrin.h;hb=HEAD#l56),
so I'm guessing vector_size implies alignment? This does not seem to be
documented anywhere obvious.

Also interesting is that icc-17 produces unaligned load/stores for the same
code, but there is no amount of __attribute__((aligned(32))) that will make
them aligned.

In any case I'll use the __m*_u types to make an unaligned version of my
memswap function.

[Bug bootstrap/78859] profiledbootstrap failure caused by -Werror=nonnull

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > (In reply to Martin Liška from comment #0)
> > > There are 2 (so far) errors reported:
> > > 
> > > 1) gengtype.c:
> > > 
> > > ../../gcc/gengtype.c: In function ‘const char*
> > > get_file_srcdir_relative_path(const input_file*)’:
> > > ../../gcc/gengtype.c:1760:14: error: argument 1 null where non-null 
> > > expected
> > > [-Werror=nonnull]
> > >if (strlen (f) > srcdir_len
> > >~~~^~~
> > > 
> > > This is real bug, following patch fixes that:
> > 
> > Only iff get_file_srcdir_relative_path is ever called with NULL inpf.  If
> > not, it is a false positive.  As strlen would crash if it is called with
> > NULL and it has not been reported yet, it clearly is not.
> 
> So with the following patch (and -disable-werror) the profiledbootstrap
> finishes:
> 
> @@ -75,9 +75,8 @@ const char *get_file_srcdir_relative_path (const
> input_file *inpf);
>  static inline const char*
>  get_input_file_name (const input_file *inpf)
>  {
> -  if (inpf)
> -  return inpf->inpname;
> -  return NULL;
> +  gcc_assert (inpf);
> +  return inpf->inpname;
>  }
> 
> Thus, it's regression.

In gengtype.c, it seems the reason for the NULL pointer checks is just a
particular, too cautious, programming style.  gen_input_file_name can return
NULL only if inpf is NULL, which can be NULL if input_file_by_name returns
NULL, which happens if it is called with NULL argument, which likely never
happens.  The question, is -Wnonnull something that should force people to
change their (sometimes weird, sure) programming styles, just to get rid of the
warning?
I believe input_file_by_name is never called with NULL, because:
epos.file = input_file_by_name (listname);
(this is after successful fopen (listname, "r"))
  if (line == 0)
break;
...
  input_file *inpf = input_file_by_name (line);
should be fine,
  if (optind >= argc)
fatal ("no source files given in plugin mode");
  nb_plugin_files = argc - optind;
  plugin_files = XNEWVEC (input_file*, nb_plugin_files);
  for (i = 0; i < (int) nb_plugin_files; i++)
{
  char *name = argv[i + optind];
  plugin_files[i] = input_file_by_name (name);
}
args before argc should also not contain NULL
  this_file = input_file_by_name (__FILE__);
  system_h_file = input_file_by_name ("system.h");
these two aren't NULL either, and then there are some uses in gengtype-state.c,
likely the state file would need to be corrupted to get NULL.

[Bug target/78853] aligned reads/writes (vmovdqa) emitted when no such guarantee can be made

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
See: http://refspecs.linuxfoundation.org/elf/x86-64-abi-0.99.pdf

[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to Vadim Zeitlin from comment #4)
> Thanks for the explanation! I didn't realize the template function below was
> smart enough to select __builtin_powil() automatically,

The template selects __builtin_powl, but gcc's optimizers know that when the
second argument has an integer value (in type long double), they can replace it
with __builtin_powil. One might complain that it only does this transformation
when the second argument is a constant, not for casts of integer variables to
long double.

> thought the comment was temporary because of the question in it: "What
> should the return type of pow(float,int) be?", which seemed to require an
> answer ("double"), but maybe it's just a figure of style I didn't understand.

I think that's the title of the DR (question mark included), check the issue
list to make sure.

> In practice, I definitely do not want to use -ffast-math (if anything, I'd
> rather use -fexcess-precision=standard but it's, unfortunately, not
> available for C++). And I can't change my (well, MinGW-w64's) libm. So,
> again, in this particular case, if I understand you correctly, it seems like
> I simply will have to live with the (very small, admittedly) loss of
> precision after migrating the existing code base from C++98 to C++11, right?

I think so.

[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11

[vz-gcc at zeitlins dot org]

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

--- Comment #6 from Vadim Zeitlin  ---
> One might complain that it only does this transformation when the second 
> argument is a constant, not for casts of integer variables to long double.

Yes, in the light of new information, this is what this bug is really about:
due to disabling the old overloads selecting __builtin_powil() explicitly, the
results are now (i.e. with C++11) different when an integer constant and an
integer variable containing the same value are used, whereas they were the same
before.

IMHO this is a regression, albeit a minor one, but I can understand if you
decide it's not worth doing anything about it -- please just close this bug in
this case.

Thanks again for your explanations!

[Bug c++/70029] [8 Regression] ICE with C++11 and -flto

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|7.0 |8.0
Summary|[7 Regression] ICE with |[8 Regression] ICE with
   |C++11 and -flto |C++11 and -flto

--- Comment #12 from Jakub Jelinek  ---
I hoped r241832 would resolve this, but it doesn't.
I agree with retargetting this to 8, but please look at it during stage1.

[Bug target/78862] New: tile*: ICE with -fstack-protetor-strong

[fw at gcc dot gnu.org]

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

Bug ID: 78862
   Summary: tile*: ICE with -fstack-protetor-strong
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: tilepro-glibc-linux

Created attachment 40369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40369&action=edit
Test case extracted from glibc

Compile the attached test case with:

tilepro-glibc-linux-gnu-gcc -c -O2 -fstack-protector-strong
tst-pthread-getattr.i

This causes an ICE:

tst-pthread-getattr.c: In function ‘allocate_and_test’:
tst-pthread-getattr.c:55:1: internal compiler error: in
dwarf2out_frame_debug_cfa_offset, at dwarf2cfi.c:1173
 }
 ^
0x64d4e8 dwarf2out_frame_debug_cfa_offset
/home/bmg/src/gcc/gcc/dwarf2cfi.c:1173
0x64d4e8 dwarf2out_frame_debug
/home/bmg/src/gcc/gcc/dwarf2cfi.c:2019
0x64d4e8 scan_insn_after
/home/bmg/src/gcc/gcc/dwarf2cfi.c:2415
0x64ebdd scan_trace
/home/bmg/src/gcc/gcc/dwarf2cfi.c:2572
0x64f64e create_cfi_notes
/home/bmg/src/gcc/gcc/dwarf2cfi.c:2611
0x64f64e execute_dwarf2_frame
/home/bmg/src/gcc/gcc/dwarf2cfi.c:2974
0x64f64e execute
/home/bmg/src/gcc/gcc/dwarf2cfi.c:3454

Version: gcc version 6.2.1 20161219 [gcc-6-branch revision 243794] (GCC) 

Other tile* targets run into similar-looking ICEs.

[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Started with r225661.

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #6 from Jerry DeLisle  ---
On my list

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
(In reply to janus from comment #2)
> I'm afraid I have too little knowledge of the I/O parts of libgfortran to
> fix, but I can at least give some pointers to where things appear to go
--- snip ---
>   if (is_internal_unit (dtp))
> ...

Internal units require special handling in many places and have a lot of corner
cases, as do namelists.

[Bug c++/78858] [7 Regression] Bogus -Wnonnull warning involving strcmp with -fsanitize=undefined

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
While we work toward a resolution it should be possible to avoid the nonnull
warnings by using the -fno-sanitize-recover=undefined option.

[Bug c/70186] RFE: better handling of misspelled attributes

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Candidate patch posted here:
  https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01610.html

[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
While this started with my commit, the actual bug is there from the start of
Cilk+ support.
The __sec_reduce_* builtins are declared with int return type, which doesn't
actual match what they return (it is in this case the type of the argument).
I bet the current way to deal with this is handle those in
resolve_overloaded_builtin and turn them into internal functions or something
similar and resolve the return type at that point.
The question is what to do with templates if the arguments are type dependent.
Another thing that is weird is that the __sec_reduce_{min,max}_ind return int,
I would have expected size_t or something more appropriate for array indexes. 
Does Cilk+ really mandate int in that case?  How can it be used on a very large
array then?

[Bug driver/78863] New: error on -fsanitize suggests invalid -fsanitize=all

[msebor at gcc dot gnu.org]

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

Bug ID: 78863
   Summary: error on -fsanitize suggests invalid -fsanitize=all
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The manual explains that the -fsanitize=all option is not allowed by GCC:

-fno-sanitize=all
This option disables all previously enabled sanitizers. -fsanitize=all is
not allowed, as some sanitizers cannot be used together.

But when GCC is invoked with just plain -fsanitize (with no = after it) GCC
gives an error as expected but then goes on to suggest that maybe the invalid
-fsanitize=all was meant.

$ echo | gcc -O2 -S -Wall -fsanitize -xc - || echo | gcc -O2 -S -Wall
-fsanitize=all -xc -
xgcc: error: unrecognized command line option ‘-fsanitize’; did you mean
‘-fsanitize=all’?
xgcc: error: -fsanitize=all option is not valid

[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

[tprince at computer dot org]

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

--- Comment #6 from tprince at computer dot org ---
__sec_reduce_{min,max}_ind in Intel cilk(tm) plus don't give good performance,
so one may suspect they are using size_t.(In reply to Jakub Jelinek from
comment #5)
> While this started with my commit, the actual bug is there from the start of
> Cilk+ support.
> The __sec_reduce_* builtins are declared with int return type, which doesn't
> actual match what they return (it is in this case the type of the argument).
> I bet the current way to deal with this is handle those in
> resolve_overloaded_builtin and turn them into internal functions or
> something similar and resolve the return type at that point.
> The question is what to do with templates if the arguments are type
> dependent.
> Another thing that is weird is that the __sec_reduce_{min,max}_ind return
> int, I would have expected size_t or something more appropriate for array
> indexes.  Does Cilk+ really mandate int in that case?  How can it be used on
> a very large array then?

[Bug rtl-optimization/78751] [7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn) w/ -Os -misel

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
In this testcase ifcvt happens upon a branch like:


(jump_insn 28 27 65 2 (set (pc)
(if_then_else (eq (reg:CCEQ 183)
(const_int 0 [0]))
(label_ref:SI 65)
(pc))) "78751-0.c":8 796 {*rs6000.md:12174}
 (expr_list:REG_DEAD (reg:CCEQ 183)
(int_list:REG_BR_PROB 5000 (nil)))


where that reg 183 is set up with


(insn 27 26 28 2 (set (reg:CCEQ 183)
(compare:CCEQ (gt:SI (reg:CC 168)
(const_int 0 [0]))
(ne:SI (reg:CC 179)
(const_int 0 [0] "78751-0.c":8 805 {*rs6000.md:12298}
 (expr_list:REG_DEAD (reg:CC 179)
(expr_list:REG_DEAD (reg:CC 168)
(nil


This is a crxor on the outputs of two compares, an unnamed
define_insn_and_split (search for "creqv or crxor" in rs6000.md).

ifcvt wants to combine this with a trap in the branch block to become
a conditional branch.  To do that, it makes insns like


(insn 63 26 64 2 (set (reg:SI 189)
(gt:SI (reg:CC 168)
(const_int 0 [0]))) -1
 (nil))
(insn 64 63 65 2 (set (reg:SI 190)
(ne:SI (reg:CC 179)
(const_int 0 [0]))) -1
 (nil))
(insn 65 64 27 2 (trap_if (ne (reg:SI 189)
(reg:SI 190))
(const_int 0 [0])) -1
 (nil))

but those do not exist (there is no pattern without clobbers for NE).

[Bug fortran/78864] New: ICE in dtio_procs_present, at fortran/resolve.c:13819

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

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

Bug ID: 78864
   Summary: ICE in dtio_procs_present, at fortran/resolve.c:13819
   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: ---

Invalid code affects version 7 since about 20160904 :


$ cat z1.f90
program p
   type t
   end type
   class(t) :: x
   namelist /nml/ x
end


$ gfortran-7-20161218 z1.f90
f951: internal compiler error: Segmentation fault
0xc513cf crash_signal
../../gcc/toplev.c:333
0x5e256d dtio_procs_present
../../gcc/fortran/resolve.c:13819
0x70083b resolve_fl_namelist
../../gcc/fortran/resolve.c:13869
0x70083b resolve_symbol
../../gcc/fortran/resolve.c:14703
0x71a01b do_traverse_symtree
../../gcc/fortran/symbol.c:3986
0x70307a resolve_types
../../gcc/fortran/resolve.c:15976
0x6febdc gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16089
0x6e8eca resolve_all_program_units
../../gcc/fortran/parse.c:5947
0x6e8eca gfc_parse_file()
../../gcc/fortran/parse.c:6194
0x72ced2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/78864] ICE in dtio_procs_present, at fortran/resolve.c:13819

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

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

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

Older versions give :


$ gfortran-7-20160828 z1.f90
z1.f90:5:16:

namelist /nml/ x
1
Error: NAMELIST object 'x' in namelist 'nml' at (1) is polymorphic and requires
a defined input/output procedure
z1.f90:4:16:

class(t) :: x
1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer

[Bug fortran/78865] New: ICE in create_tmp_var, at gimple-expr.c:473

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

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

Bug ID: 78865
   Summary: ICE in create_tmp_var, at gimple-expr.c:473
   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: ---

Affects version 7 down to at least 4.8, at -Os, -O2 or higher :


$ cat z1.f90
program p
   call sub (3)
end
subroutine sub (x)
   integer :: x, i, n
   do i = 1, x
  if ( n /= 0 ) stop
  call sub2
   end do
   print *, x, n
end
subroutine sub2
   call sub (*99)
99 stop
end


$ gfortran-7-20161218 -O2 z1.f90
z1.f90:3:0:

 end

internal compiler error: in create_tmp_var, at gimple-expr.c:473
0x9acb93 create_tmp_var(tree_node*, char const*)
../../gcc/gimple-expr.c:473
0x9acbb8 create_tmp_reg(tree_node*, char const*)
../../gcc/gimple-expr.c:489
0x1369556 split_function
../../gcc/ipa-split.c:1664
0x1369556 execute_split_functions
../../gcc/ipa-split.c:1865

[Bug fortran/78866] New: ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

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

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

Bug ID: 78866
   Summary: ICE in gimplify_adjust_omp_clauses_1, at
gimplify.c:8721
   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: ---

Follow-up of pr77973 :


$ cat z1.f90
subroutine s(x)
   integer :: x(*)
!$omp parallel
!$omp target
   x(1) = 1
!$omp end target
!$omp end parallel
end


$ gfortran-7-20161218 -fopenmp -c z1.f90
z1.f90:4:0:

 !$omp target

internal compiler error: Segmentation fault
0xc513cf crash_signal
../../gcc/toplev.c:333
0x9e6ab1 gimplify_adjust_omp_clauses_1
../../gcc/gimplify.c:8721
0x148d28e splay_tree_foreach_helper
../../libiberty/splay-tree.c:242
0x148d28e splay_tree_foreach
../../libiberty/splay-tree.c:566
0x9d4e07 gimplify_adjust_omp_clauses
../../gcc/gimplify.c:9130
0x9f3909 gimplify_omp_workshare
../../gcc/gimplify.c:10528
0x9d85ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11682
0x9dcef6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6460
0x9de1dd gimplify_bind_expr
../../gcc/gimplify.c:1277
0x9d98ed gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11384
0x9dcef6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6460
0x9de1dd gimplify_bind_expr
../../gcc/gimplify.c:1277
0x9d98ed gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11384
0x9dcef6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6460
0x9db735 gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:435
0x9db735 gimplify_and_return_first
../../gcc/gimplify.c:447
0x9db735 gimplify_omp_parallel
../../gcc/gimplify.c:9287
0x9db735 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11644
0x9dcef6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6460
0x9de1dd gimplify_bind_expr
../../gcc/gimplify.c:1277

[Bug fortran/78866] ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

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

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

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

Older versions down to at least 5.4.1 give :


$ gfortran-7-20161023 -fopenmp -c z1.f90
z1.f90:4:0:

 !$omp target

internal compiler error: Segmentation fault
0xc32b7f crash_signal
../../gcc/toplev.c:338
0x957a20 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3154
0x957a20 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2213
0xb2c8e7 lower_omp_target
../../gcc/omp-low.c:16209
0xb2c8e7 lower_omp_1
../../gcc/omp-low.c:17084
0xb2c8e7 lower_omp
../../gcc/omp-low.c:17177
0xb2abec lower_omp_1
../../gcc/omp-low.c:17025
0xb2abec lower_omp
../../gcc/omp-low.c:17177
0xb38f8a lower_omp_taskreg
../../gcc/omp-low.c:15659
0xb2aee6 lower_omp_1
../../gcc/omp-low.c:17033
0xb2aee6 lower_omp
../../gcc/omp-low.c:17177
0xb2abec lower_omp_1
../../gcc/omp-low.c:17025
0xb2abec lower_omp
../../gcc/omp-low.c:17177
0xb31dcf execute_lower_omp
../../gcc/omp-low.c:17912
0xb31dcf execute
../../gcc/omp-low.c:17949

[Bug c++/78840] [5/6/7 Regression] ICE with const variables in templates implicitly captured by nested lambda expressions

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/78842] "error: declaration of 'bool icase' shadows a parameter" should be warning

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #2 from Nathan Sidwell  ---
Created attachment 40370
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40370&action=edit
trimmed testcase

[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

[bugzilla at halpernwightsoftware dot com]

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

Pablo Halpern  changed:

   What|Removed |Added

 CC||bugzilla@halpernwightsoftwa
   ||re.com

--- Comment #7 from Pablo Halpern  ---
This bug should be renamed "[5/6/7 Regression] cilkplus __sec_reduce_add ICE",
as it has nothing to do with task-based reducers, which use a totally different
mechanism.

[Bug middle-end/78622] [7 Regression] -Wformat-length/-fprintf-return-value incorrect with overflow/wrapping

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #5)
> Author: jvdelisle
> Date: Fri Dec 16 20:27:51 2016
> New Revision: 243765
> 
Wrong PR number, my apologies.

[Bug fortran/78662] [F03] Incorrect parsing of quotes in the char-literal-constant of the DT data descriptor

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #4 from Jerry DeLisle  ---
This is fixed, I slipped a digit in the PR number , will fix changelogs at next
opportunity.

Author: jvdelisle
Date: Fri Dec 16 20:27:51 2016
New Revision: 243765

URL: https://gcc.gnu.org/viewcvs?rev=243765&root=gcc&view=rev
Log:
2016-12-16  Jerry DeLisle  

PR fortran/78622
* io.c (format_lex): Continue of string delimiter seen.

* io/transfer.c (get_dt_format): New static function to alloc
and set the DT iotype string, handling doubled quotes.
(formatted_transfer_scalar_read,
formatted_transfer_scalar_write): Use new function.

* gfortran.dg/dtio_20.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_20.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
(In reply to janus from comment #8)

The case that ICEs needs to have an error check in io.c (gfc_resolve_dt). I
have found the location and now need to build the error check.

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

[Casey at Carter dot net]

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

--- Comment #2 from Casey Carter  ---
Created attachment 40371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40371&action=edit
compressed preprocessed repro

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Markus Trippelsdorf  ---
Thanks.
The issue is already fixed on the gcc-6 branch.
(gcc-6.3, with the fix included, will be released in the coming days)

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #13 from Jerry DeLisle  ---
*** Bug 78864 has been marked as a duplicate of this bug. ***

[Bug fortran/78864] ICE in dtio_procs_present, at fortran/resolve.c:13819

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #2 from Jerry DeLisle  ---
This is a DUP of reopened 78659, I will include your test case as part of it.

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

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[damian at sourceryinstitute dot org]

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

--- Comment #6 from Damian Rouson  ---
Please let me know which day this hit (or will hit) the trunk.  I'm currently
using a build dated 20161215.

[Bug c++/78842] "error: declaration of 'bool icase' shadows a parameter" should be warning

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Nathan Sidwell from comment #2)
> Created attachment 40370 [details]
> trimmed testcase

Isn't this from PR78840 instead?

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[vehre at gmx dot de]

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

--- Comment #7 from Andre Vehreschild  ---
As you can see from the commit message in comment #3 it hit trunk on 9th of
Dezember.

Am 19. Dezember 2016 21:03:38 MEZ, schrieb damian at sourceryinstitute dot org
:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78505
>
>--- Comment #6 from Damian Rouson 
>---
>Please let me know which day this hit (or will hit) the trunk.  I'm
>currently
>using a build dated 20161215.

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
On the trunk this got fixed with r241775, and r241788 then backported it to 6.x
branch (haven't verified on the branch though).  So maybe dup of PR78047.

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

[Casey at Carter dot net]

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

--- Comment #5 from Casey Carter  ---
I have verified that gcc-6-branch compiles the repro correctly, so yes, this is
a dup of PR78047.

[Bug c++/78841] [6 regression] optimizer bug (silent bad codegen)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #6 from Markus Trippelsdorf  ---
dup

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

[Bug middle-end/78047] [5 Regression] Chromium apparently gets miscompiled

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #12 from Markus Trippelsdorf  ---
*** Bug 78841 has been marked as a duplicate of this bug. ***

[Bug middle-end/78047] [5 Regression] Chromium apparently gets miscompiled

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #13 from Markus Trippelsdorf  ---
Fixed, BTW.

[Bug middle-end/78047] [5 Regression] Chromium apparently gets miscompiled

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #14 from Markus Trippelsdorf  ---
(In reply to Markus Trippelsdorf from comment #13)
> Fixed, BTW.

No, it is still waiting for a gcc-5 backport.

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[damian at sourceryinstitute dot org]

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

--- Comment #8 from Damian Rouson  ---
Thanks.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
(In reply to Peter Bergner from comment #8)

> where "src" is the subreg:SI ..., so the new_reg mode will be SImode and we
> then replace the whole SET_SRC (curr_insn_set) which is the subreg:SI
> (reg:DF ...) which doesn't seem correct.
> 
> Vlad, should we have never got this far into check_and_process_move() with
> this type of insn?  Adding an ugly hack that creates an early out for this
> insn (ie, set (reg:SI) (subreg:SI (reg:DF))) seems to make us compile.
> 

I believe we should process this insn in check_and_process_move.  It is the
single place to check secondary reload hooks and insns.

> If we are supposed to still process this insn, then how about something like
> the following patch that creates a new_reg with the mode of the src register
> and not the subreg and then replacing that instead of the entire subreg src?
> This too eliminates the SEGV/ICE.

I think creating a new reg from the register instead of the sub-register is
safer.  Also it results in a better code too, if the subregister is a
paradoxical one,  So the patch idea is right.  But I believe it is not
finished.  I am attaching a new version of the patch.  If it is ok, I can
commit it after your confirmation.

[Bug fortran/78867] New: GFortran function returning string ICE with -flto

[jb at gcc dot gnu.org]

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

Bug ID: 78867
   Summary: GFortran function returning string ICE with -flto
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

The following testcase fails when compiled with -flto. Enabling optimization
makes it work, e.g. "-O1 -flto".

! { dg-do compile }
! { dg-options "-flto" }
program test
  if (len(bar(2_8)) /= 2_8) call abort
contains

  function bar(i)
integer(8), intent(in) :: i
character(len=i) :: bar

bar = ""
  end function bar

end program test


Backtrace:

lto1: internal compiler error: Segmentation fault
0xb7daa6 crash_signal
../../trunk-git/gcc/toplev.c:333
0x9ec02b lto_input_tree_ref(lto_input_block*, data_in*, function*, LTO_tags)
../../trunk-git/gcc/lto-streamer-in.c:332
0x9ec21d lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../trunk-git/gcc/lto-streamer-in.c:1446
0x9ec65e lto_input_tree(lto_input_block*, data_in*)
../../trunk-git/gcc/lto-streamer-in.c:1492
0xe590db lto_input_ts_exp_tree_pointers
../../trunk-git/gcc/tree-streamer-in.c:893
0xe5c1f6 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
../../trunk-git/gcc/tree-streamer-in.c:1079
0x9eb499 lto_read_tree_1
../../trunk-git/gcc/lto-streamer-in.c:1333
0x9eb53a lto_read_tree
../../trunk-git/gcc/lto-streamer-in.c:1363
0x9ec3c2 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../trunk-git/gcc/lto-streamer-in.c:1475
0x9ec478 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*)
../../trunk-git/gcc/lto-streamer-in.c:1387
0x9ec64c lto_input_tree(lto_input_block*, data_in*)
../../trunk-git/gcc/lto-streamer-in.c:1490
0x9ee6ed input_function
../../trunk-git/gcc/lto-streamer-in.c:1045
0x9ef07f lto_read_body_or_constructor
../../trunk-git/gcc/lto-streamer-in.c:1259
0x9ef408 lto_input_function_body(lto_file_decl_data*, cgraph_node*, char
const*)
../../trunk-git/gcc/lto-streamer-in.c:1307
0x6b282b cgraph_node::get_untransformed_body()
../../trunk-git/gcc/cgraph.c:3581
0x6c26d6 cgraph_node::expand()
../../trunk-git/gcc/cgraphunit.c:1971
0x6c3765 output_in_order
../../trunk-git/gcc/cgraphunit.c:2244
0x6c4224 symbol_table::compile()
../../trunk-git/gcc/cgraphunit.c:2488
0x6028b5 lto_main()
../../trunk-git/gcc/lto/lto.c:3330
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gfortran returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status



The problem seems to be related to the typecasting needed when converting the
integer(kind=8) variables to character length variables (which on trunk are
integer(kind=4). If one changes the testcase to use default kind integers, it
works.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov  ---
Created attachment 40372
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40372&action=edit
The proposed patch

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[jsm28 at gcc dot gnu.org]

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

--- Comment #12 from Joseph S. Myers  ---
Created attachment 40373
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40373&action=edit
fnmatch.i preprocessed source

With that new LRA patch (plus the previous gcc-pr78516.v2.diff) I get an ICE
building glibc again.  Preprocessed source attached.  Compile with:

powerpc-linux-gnuspe-gcc -S -std=gnu11 -fgnu89-inline  -O2
-fmerge-all-constants -g -mlong-double-128 -ftls-model=initial-exec fnmatch.i

In file included from fnmatch.c:321:0:
fnmatch_loop.c: In function 'internal_fnwmatch':
fnmatch_loop.c:999:1: internal compiler error: Segmentation fault
0x8784a4a crash_signal
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/toplev.c:333
0x861e590 lra_eliminate_reg_if_possible(rtx_def**)
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-eliminations.c:1385
0x860dd08 in_class_p
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-constraints.c:257
0x8613721 process_alt_operands
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-constraints.c:2239
0x8619052 curr_insn_transform
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-constraints.c:3720
0x861be7a lra_constraints(bool)
   
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra-constraints.c:4706
0x8606dbe lra(_IO_FILE*)
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/lra.c:2377
0x85bdf74 do_reload
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/ira.c:5400
0x85bdf74 execute
/scratch/jmyers/glibc/pe500-mainline/src/gcc-mainline/gcc/ira.c:5584
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #13 from Peter Bergner  ---
(In reply to Vladimir Makarov from comment #11)
> Created attachment 40372 [details]
> The proposed patch

Agreed your additions to my change looks good.  However, I'm not so sure about
this last hunk:

-SET_SRC (curr_insn_set) = new_reg;
+{
+  SET_SRC (curr_insn_set) = new_reg;
+  if (SUBREG_P (src))
+   SUBREG_REG (SET_SRC (curr_insn_set)) = new_reg;
+  else
+   SET_SRC (curr_insn_set) = new_reg;
+}

Specifically, I don't think you meant to leave the following code as part of
that:

+  SET_SRC (curr_insn_set) = new_reg;

since after we execute that, SET_SRC (curr_insn_set) won't be
a subreg anymore and the following:

+   SUBREG_REG (SET_SRC (curr_insn_set)) = new_reg;

won't end well.  I think we want your patch minus that one line.

Re: Problem with Factory Generated code g++ 4.x, 5.x, 6.x

[Jim Wilson]

On 12/18/2016 12:15 PM, Eduardo Yÿffe1nez via gcc-bugs wrote:
>I wish to report a problem with g++ 4.x, g++ 5.x, g++ 6.x. I'm trying 
>to implement a very classic Factory Method Pattern in C++, I can do it 
>very easily in MS-Visual C++, but in Linux with g++ the code compiles 
>but I get a segmentation fault when I run it. The code is very simple 
>to follow and I reduced it to a very academic code example to try to 
>diagnose the problem. I am building with the C++11 version.


It looks like a global static initializer ordering problem.  You have 
two variables with static initializers: TResourceMap Factory::registry 
and BrandsFactory BrandsFactory::createThisFactory.  The initializer for 
createThisFactory is referring to the registry variable.  If the 
initializer for createThisFactory runs first, then it is referencing an 
uninitialized variable, and the code crashes.


Order of global static initializers is probably unspecified or 
undefined.  I don't have a copy of the C++ standard handy.


I can reproduce the problem on linux if I put brands.cpp before 
resourcefactory.cpp on the link line.  The code works if I put 
brands.cpp after resourcefactory.cpp on the link line.  Changing the 
link order is changing the static initializer order.


Jim

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #14 from Peter Bergner  ---
(In reply to Joseph S. Myers from comment #12)
> Created attachment 40373 [details]
> fnmatch.i preprocessed source
> 
> With that new LRA patch (plus the previous gcc-pr78516.v2.diff) I get an ICE
> building glibc again.  Preprocessed source attached.  Compile with:

Joseph, can you retry but with removing the one line I said I don't think we
want from Vlad's patch?  I'm pretty sure that is probably causing your ICE.  So
the last hunk should look like:

+{
+  if (SUBREG_P (src))
+   SUBREG_REG (SET_SRC (curr_insn_set)) = new_reg;
+  else
+   SET_SRC (curr_insn_set) = new_reg;
+}

[Bug target/78683] [ppc] __builtin_ctzl code gen can be improved for -mcpu=power8 and earlier

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Fixed.

[Bug fortran/78867] [7 Regression] GFortran function returning string ICE with -flto

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||5.4.0, 6.2.0
Version|unknown |7.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-12-20
 Ever confirmed|0   |1
Summary|GFortran function returning |[7 Regression] GFortran
   |string ICE with -flto   |function returning string
   ||ICE with -flto
  Known to fail||7.0

--- Comment #1 from Dominique d'Humieres  ---
This seems to be a regression between revisions r243624 (2016-12-13, compiles)
and r243765 (2016-12-16, ICE with -m32 or -m64).

[Bug fortran/78865] ICE in create_tmp_var, at gimple-expr.c:473

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-20
 Ever confirmed|0   |1

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

[Bug fortran/78866] ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-20
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.9 up to trunk. 4.8 does not know

!$omp target
  1
Error: Unclassifiable OpenMP directive at (1)

[Bug c/78868] New: When one variadic function calls another one, the parameters are reversed, if va_arg is used directly in function call.

[vlad at cloudflare dot com]

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

Bug ID: 78868
   Summary: When one variadic function calls another one, the
parameters are reversed, if va_arg is used directly in
function call.
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vlad at cloudflare dot com
  Target Milestone: ---

Created attachment 40374
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40374&action=edit
Preprocessed source file

On Debian 8, when using gcc 4.9.2, when one variadic function calls another
one, the parameters are reversed, if va_arg is used directly in function call.
When va_arg is evaluated before the call into a temporary location, the order
is correct.

Also replicated in gcc 5.3.1.

Clang shows the expected behavior.

#include 

int printf( const char* format, ... );

void vararg1(int n, ...) {
  va_list args;
  va_start(args, n);
  printf("%d, %d\n", va_arg(args, int), va_arg(args, int));
  va_end(args);
}

void vararg2(int n, ...) {
  va_list args;
  va_start(args, n);
  int a = va_arg(args, int);
  int b = va_arg(args, int);
  printf("%d, %d\n", a, b);
  va_end(args);
}

int main() {
  vararg1(2, 12, 13);
  vararg2(2, 12, 13);
  return 0;
}

Gcc output:
13, 12
12, 13

Clang output:
12, 13
12, 13

[Bug c/78868] When one variadic function calls another one, the parameters are reversed, if va_arg is used directly in function call.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>  printf("%d, %d\n", __builtin_va_arg(args,int), __builtin_va_arg(args,int));


The order of execution here is not specified in the C standard.  So either of
the var_arg could be executed first.