[Bug target/83013] MicroBlaze - #ident - Error: operation combines symbols in different segments

[nathan at nathanrossi dot com]

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

--- Comment #2 from nathan at nathanrossi dot com ---
One solution to this bug is to remove the microblaze specific emission of ident
use the default which emits .ident directives for the assembler.

I've sent a patch which makes this change:

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01279.html

[Bug target/83013] MicroBlaze - #ident - Error: operation combines symbols in different segments

[nathan at nathanrossi dot com]

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

--- Comment #1 from nathan at nathanrossi dot com ---
Created attachment 42619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42619=edit
output assembly

[Bug target/83013] New: MicroBlaze - #ident - Error: operation combines symbols in different segments

[nathan at nathanrossi dot com]

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

Bug ID: 83013
   Summary: MicroBlaze - #ident - Error: operation combines
symbols in different segments
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at nathanrossi dot com
  Target Milestone: ---

Created attachment 42618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42618=edit
pre-processed source

When compiling certain code which uses the #ident directive the output assembly
is broken with content being located in .sdata2 instead of .text.

See attached pre-processed basename.i from the shadow package.

microblazeel-oe-linux-gcc \
  -mcpu=v10.0 -mlittle-endian -mxl-barrel-shift -mxl-pattern-compare
-mxl-reorder \
  -mno-xl-soft-mul -mxl-multiply-high -mno-xl-soft-div -mhard-float \
  -O2 -g -c \
  -o basename.o \
  -save-temps \
  basename.i

basename.s: Assembler messages:
basename.s:961: Error: operation combines symbols in different segments
basename.s:962: Error: operation combines symbols in different segments
basename.s:965: Error: operation combines symbols in different segments
basename.s:966: Error: operation combines symbols in different segments
basename.s:969: Error: operation combines symbols in different segments
basename.s:970: Error: operation combines symbols in different segments
basename.s:976: Error: operation combines symbols in different segments
basename.s:977: Error: operation combines symbols in different segments
basename.s:980: Error: operation combines symbols in different segments
basename.s:981: Error: operation combines symbols in different segments
basename.s:987: Error: operation combines symbols in different segments
basename.s:988: Error: operation combines symbols in different segments
basename.s:991: Error: operation combines symbols in different segments
basename.s:992: Error: operation combines symbols in different segments
basename.s:997: Error: operation combines symbols in different segments
basename.s:998: Error: operation combines symbols in different segments

As can be seen in the output basename.s, the section is setup to be .text at
the beginning, but is switched to .sdata2 for the ident content but then never
changed back to .text.

.text
$Ltext0:
#APP
.sdata2
.ascii "$Id$\0"

#NO_APP
.align  2
.globl  Basename
$LFB35:
$LM1:
.entBasename
.type   Basename, @function
Basename:
.frame  r1,32,r15   # vars= 0, regs= 1, args= 24
.mask   0x00088000
$LVL0:
addik   r1,r1,-32

Which results in the $LVL0-$Ltext0 (and others) crossing sections.

This may be a duplicate of a previously reported bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63261

[Bug target/82983] [8 Regression] ICE in extract_insn, at recog.c:2305 w/ GFMI

[kyukhin at gcc dot gnu.org]

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

--- Comment #1 from Kirill Yukhin  ---
Author: kyukhin
Date: Thu Nov 16 06:14:54 2017
New Revision: 254797

URL: https://gcc.gnu.org/viewcvs?rev=254797=gcc=rev
Log:
Fix GFNI check which didn't work properly in gfni+sse case

gcc/
PR target/82983
* config/i386/gfniintrin.h: Add sse check.
* config/i386/i386.c (ix86_expand_builtin): Fix gfni check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/gfniintrin.h
trunk/gcc/config/i386/i386.c

[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel

[wilson at gcc dot gnu.org]

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

--- Comment #12 from Jim Wilson  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Jim Wilson from comment #9)
> > This requires either a linux kernel longlong.h fix to use an alternate macro
> > definition for mips targets that don't directly support TImode multiply.  Or
> > else it requires a gcc mips maintainer to fix the mips backend to add multi3
> > support for mips64r6.  Either one should be possible by emitting two
> > multiply instructions, one for the high part and one for the low part.
> 
> The middle-end has support already for mult_highpart optab, low is the same
> as mult optab (for the smaller mode), emitting this from the expr.c should
> be easy to add rather than changing most of the back-ends to add a multi3
> optab.

This is mips specific code in the kernel to do a multi3 (actually I think
mulditi3).  So this isn't a generic gcc problem affecting all targets.  If you
don't want the kernel doing this, then fix the kernel.

The mips port already has a mulditi3 pattern, it is just lacking mips64r6
support.  It looks like an oversight that should be fixed.

You are right that expand_expr could synthesize a mulditi3 if muldi3_highpart
is available, but it isn't clear if that is the right fix.  Note that if we
adopt this solution, then effectively you are forcing backends to implement a
muldi3_highpart pattern.  How is this any different than forcing them to
implement a mulditi3 pattern?  That doesn't make any sense.

Also, note, that Jakub patch generates muldi3_highpart is mulditi3 fails.  If
we fix mulditi3 expansion to call muldi3_highpart, then that appears to make
part of Jakub's patch unnecessary.

I think it would be better to fix the mips mulditi3 pattern, or fix the kernel
umul_ppmm macro to avoid the problem.

[Bug c/83011] -Wformat-truncation wrongly computes length (depends on the position of numbers in the addition)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-16
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I cannot reproduce any warnings with the INN function (extracted from timer.c),
either with the top of trunk (GCC 8) or with the top of GCC 7-branch.  Can you
provide a preprocessed translation unit (the result of compiling timer.c with
-E instead of -c), and the compiler options?

I think in English the note would read like:

  snprintf output 2 or more bytes (assuming 3) into a destination of size 1

This is issued when the output is in some range where the lower bound would fit
but the upper bound would not.  Since the string is an argument and the buffer
size depends on timer_count which also unknown it's not clear to me what the
range is being determined from.  Are you using -flto to build the project?

[Bug fortran/83012] New: Simply contiguous pointer function not recognized as contiguous

[neil.n.carlson at gmail dot com]

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

Bug ID: 83012
   Summary: Simply contiguous pointer function not recognized as
contiguous
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

In the following example the pointer assignment "p => x%dataptr()" is rejected
because the compiler does not recognize the function result x%dataptr() as
contiguous when in fact it is simply contiguous by definition.  Note that there
is no error if the dummy variable x is declared as type(x) instead of class(x).

FWIW, the 6.4.1 compiler has no problems with this example.

module mod
  type :: foo
integer, pointer, contiguous :: p(:)
  contains
procedure :: dataptr
  end type
contains
  function dataptr(this) result(dp)
class(foo), intent(in) :: this
integer, pointer, contiguous :: dp(:)
dp => this%p
  end function
end module

subroutine bar(x)
  use mod
  class(foo) :: x
  integer, pointer, contiguous :: p(:)
  p => x%dataptr()
end subroutine

The error message:

$ gfortran --version
GNU Fortran (GCC) 8.0.0 20171115 (experimental)

$ gfortran -c bug.f90 
bug.f90:19:7:

   p => x%dataptr()
   1
Error: Assignment to contiguous pointer from non-contiguous target at (1)

[Bug c/80354] Poor support to silence -Wformat-truncation=1

[toojays at toojays dot net]

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

John Steele Scott  changed:

   What|Removed |Added

 CC||toojays at toojays dot net

--- Comment #6 from John Steele Scott  ---
(In reply to Stephan Bergmann from comment #5)
> (In reply to Martin Sebor from comment #3)
> > The warning does just what it's designed to do: point out the potential
> > unhandled truncation.
> 
> But it is unusable in practice if there is no reliable way to silence false
> positives.

^- This!

A simple cast-to-void is the conventional way to indicate to the compiler that
it should consider the value as having been consumed even though it wasn't
really. It's a real shame if this information is not available to the code that
generates this warning.

(In reply to Martin Sebor from comment #1)
> Besides actually handling the truncation (e.g., branching on
> it and taking some action that does affect the behavior), storing the return
> value in a volatile variable and reading it should suppress it.

Thanks for the tip. For isolated instances this may be less invasive than what
I have been contemplating (checking the return value and calling some no-op
function). It would be better if there were some solution that didn't generate
unnecessary code though.

[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #11 from Steve Ellcey  ---
Fixed on Tot for 8.0.

[Bug fortran/82996] ICE and segfault with derived type finalization

[neil.n.carlson at gmail dot com]

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

--- Comment #5 from neil.n.carlson at gmail dot com ---
I've built the svn trunk and tested the examples with it.  The ICEs with the
comment 2 and 3 examples are gone, as Dominique found.  The comment 1 example
continues to segfault when executed, as does the comment 2 example now.  The
comment 3 example executes without error.  I think Dominique swapped 2 and 3.

[Bug c/83011] New: -Wformat-truncation wrongly computes length (depends on the position of numbers in the addition)

[julien at trigofacile dot com]

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

Bug ID: 83011
   Summary: -Wformat-truncation wrongly computes length (depends
on the position of numbers in the addition)
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julien at trigofacile dot com
  Target Milestone: ---

Hi,

Trying to build INN, I encounter the following warning:

timer.c: Dans la fonction « TMRsummary »:
timer.c:395:37: error: la sortie de la directive «   » peut être tronquée en
écrivant 1 octet dans une région dont la taille est comprise entre 0 et 1
[-Werror=format-truncation=]
 rc = snprintf(buf, len, "%s ", prefix);
~ 
timer.c:395:12: note: « snprintf » écrit 2 octets ou plus (3 supposé) dans une
destination dont la taille est 1
 rc = snprintf(buf, len, "%s ", prefix);
 ~~~^~~


It happens in:
  https://inn.eyrie.org/trac/browser/trunk/lib/timer.c

len = 52 * timer_count + 27 + (prefix == NULL ? 0 : strlen(prefix)) + 1;
buf = xmalloc(len);
off = 0;
if (prefix == NULL)
rc = 0;
else
rc = snprintf(buf, len, "%s ", prefix);


If I rewrite len this way, gcc no longer gives the above warning:

len = 1 + 52 * timer_count + 27 + (prefix == NULL ? 0 : strlen(prefix));


Isn't there a computation issue? (depending on the location of components in
the addition)

Julien

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[trippels at gcc dot gnu.org]

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

--- Comment #25 from Markus Trippelsdorf  ---
Ryzen is -march=znver1.

[Bug testsuite/82988] [8 regression] g++.dg/cpp0x/lambda/lambda-switch.C fail

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Nov 15 20:57:10 2017
New Revision: 254786

URL: https://gcc.gnu.org/viewcvs?rev=254786=gcc=rev
Log:
PR testsuite/82988 - g++.dg/cpp0x/lambda/lambda-switch.C fail

gcc/testsuite/ChangeLog:

PR testsuite/82988
* g++.dg/cpp0x/lambda/lambda-switch.C: Prune unimportant warning.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-switch.C

[Bug testsuite/82988] [8 regression] g++.dg/cpp0x/lambda/lambda-switch.C fail

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
  Component|c++ |testsuite
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
Test adjusted in r254786.

[Bug debug/83010] New: DW_AT_location is not emitted for thread local variable

[qiyao at gcc dot gnu.org]

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

Bug ID: 83010
   Summary: DW_AT_location is not emitted for thread local
variable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qiyao at gcc dot gnu.org
  Target Milestone: ---

$ cat 1.c
__thread int a_thread_local;

$ gcc -g -c 1.c -o 1.o

$ readelf -wi ./1.o

<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x38): GNU C17
8.0.0 20171102 (experimental) -mlittle-endian -mabi=lp64 -g
<10>   DW_AT_language: 12 (ANSI C99)
<11>   DW_AT_name: 1.c
<15>   DW_AT_comp_dir: (indirect string, offset: 0x0): gdb
<19>   DW_AT_stmt_list   : 0x0
<1><1d>: Abbrev Number: 2 (DW_TAG_variable)
<1e>   DW_AT_name: (indirect string, offset: 0x29): a_thread_local
<22>   DW_AT_decl_file   : 1
<23>   DW_AT_decl_line   : 1
<24>   DW_AT_decl_column : 14
<25>   DW_AT_type: <0x29>
<29>   DW_AT_external: 1

DW_AT_location is missing, so GDB can't locate this variable.  However, on arm
and x86_64, DW_AT_location is emitted.

x86_64:
 <1><1d>: Abbrev Number: 2 (DW_TAG_variable)
<1e>   DW_AT_name: (indirect string, offset: 0x3e): a_thread_local
<22>   DW_AT_decl_file   : 1
<23>   DW_AT_decl_line   : 1
<24>   DW_AT_type: <0x33>
<28>   DW_AT_external: 1
<28>   DW_AT_location: 10 byte block: e 0 0 0 0 0 0 0 0 e0
(DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)

arm:
<1><1d>: Abbrev Number: 2 (DW_TAG_variable)
<1e>   DW_AT_name: (indirect string, offset: 0xa2): a_thread_local
<22>   DW_AT_decl_file   : 1
<23>   DW_AT_decl_line   : 1
<24>   DW_AT_type: <0x2f>
<28>   DW_AT_external: 1
<28>   DW_AT_location: 6 byte block: c 0 0 0 0 e0
(DW_OP_const4u: 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[ebotcazou at gcc dot gnu.org]

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

--- Comment #24 from Eric Botcazou  ---
> Thanks. I can confirm it works for me!

But it doesn't for me.  What does -march=native expand to on your machine?

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
What I meant was this part of resolve_mask_arg :

  /* In the library, we access the mask with a GFC_LOGICAL_1
 argument.  No need to waste memory if we are about to create
 a temporary array.  */
  if (mask->expr_type == EXPR_OP && mask->ts.kind != 1)
{
  ts.type = BT_LOGICAL;
  ts.kind = 1;
  gfc_convert_type_warn (mask, , 2, 0);

[Bug tree-optimization/82985] [7 Regression] ICC: in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1722

[BlenderEi at LwTV dot de]

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

--- Comment #21 from BlenderEi at LwTV dot de ---
Thank you for your fast actions.
Best regards!

[Bug target/82990] Update the default -mzeroupper setting

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed.

[Bug target/82990] Update the default -mzeroupper setting

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Nov 15 19:30:58 2017
New Revision: 254783

URL: https://gcc.gnu.org/viewcvs?rev=254783=gcc=rev
Log:
i386: Add X86_TUNE_EMIT_VZEROUPPER

Add X86_TUNE_EMIT_VZEROUPPER to indicate if vzeroupper instruction should
be inserted before a transfer of control flow out of the function.  It is
turned on by default unless we are tuning for KNL.  Users can always use
-mzeroupper or -mno-zeroupper to override X86_TUNE_EMIT_VZEROUPPER.

gcc/

PR target/82990
* config/i386/i386.c (pass_insert_vzeroupper::gate): Remove
TARGET_AVX512ER check.
(ix86_option_override_internal): Set MASK_VZEROUPPER if
neither -mzeroupper nor -mno-zeroupper is used and
TARGET_EMIT_VZEROUPPER is set.
* config/i386/i386.h (TARGET_EMIT_VZEROUPPER): New.
* config/i386/x86-tune.def: Add X86_TUNE_EMIT_VZEROUPPER.

gcc/testsuite/

PR target/82990
* gcc.target/i386/pr82942-2.c: Add -mtune=knl.
* gcc.target/i386/pr82990-1.c: New test.
* gcc.target/i386/pr82990-2.c: Likewise.
* gcc.target/i386/pr82990-3.c: Likewise.
* gcc.target/i386/pr82990-4.c: Likewise.
* gcc.target/i386/pr82990-5.c: Likewise.
* gcc.target/i386/pr82990-6.c: Likewise.
* gcc.target/i386/pr82990-7.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82990-1.c
trunk/gcc/testsuite/gcc.target/i386/pr82990-2.c
trunk/gcc/testsuite/gcc.target/i386/pr82990-3.c
trunk/gcc/testsuite/gcc.target/i386/pr82990-4.c
trunk/gcc/testsuite/gcc.target/i386/pr82990-5.c
trunk/gcc/testsuite/gcc.target/i386/pr82990-6.c
trunk/gcc/testsuite/gcc.target/i386/pr82990-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/config/i386/x86-tune.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr82942-2.c

[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Jim Wilson from comment #9)
> This requires either a linux kernel longlong.h fix to use an alternate macro
> definition for mips targets that don't directly support TImode multiply.  Or
> else it requires a gcc mips maintainer to fix the mips backend to add multi3
> support for mips64r6.  Either one should be possible by emitting two
> multiply instructions, one for the high part and one for the low part.

The middle-end has support already for mult_highpart optab, low is the same as
mult optab (for the smaller mode), emitting this from the expr.c should be easy
to add rather than changing most of the back-ends to add a multi3 optab.

[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel

[wilson at gcc dot gnu.org]

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

--- Comment #10 from Jim Wilson  ---
Created attachment 42617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42617=edit
mips64r6 linux kernel .config file

Linux kernel config file to reproduce the linux kernel link failure.

[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel

[wilson at gcc dot gnu.org]

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

--- Comment #9 from Jim Wilson  ---
Jakub's patch fixes the optimization problem with the testcase.

I tried a linux kernel build with the patched compiler and the provided .config
file.  I still see some __multi3 calls.  However, looking at the code, I see in
lib/mpi/ several files with calls to umul_ppmm from a longlong.h file similar
to the one in gcc, that has

#if (defined(__mips) && __mips >= 3) && W_TYPE_SIZE == 64
#if (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
#define umul_ppmm(w1, w0, u, v) \
do {\
typedef unsigned int __ll_UTItype __attribute__((mode(TI)));\
__ll_UTItype __ll = (__ll_UTItype)(u) * (v);\
w1 = __ll >> 64;\
w0 = __ll;  \
} while (0)
#elif ...

So this is self inflicted damage, as this is an explicit TImode multiply for
gcc 5 and later.

This requires either a linux kernel longlong.h fix to use an alternate macro
definition for mips targets that don't directly support TImode multiply.  Or
else it requires a gcc mips maintainer to fix the mips backend to add multi3
support for mips64r6.  Either one should be possible by emitting two multiply
instructions, one for the high part and one for the low part.

Or it requires adding a mips assembly __multi3 function to the linux kernel. 
Or maybe the config file can be modified to drop the mpi support?

[Bug tree-optimization/83007] [8 Regression] -Wstringop-overflow false positive

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Martin Sebor  ---
A common mistake with strncat is to specify as the bound the source of the
source string (instead of the remaining space in the destination), as in:

  char d[8] = "1234";
  const char *s = "4567";

  strncat (d, s, strlen (s));

where the strncat call overflows the destination.

Something similar happens in the test case in comment #0, except there the
amount of space in the destination isn't as obvious.  The checker tries to
compute the size of the destination to see if the call can overflow but that
computation fails (it happens too early, before the size is available).  So out
of an abundance of caution, the checker points out that the bound equals the
source length, before the strncat call is folded into memcpy.  Unfortunately,
there is no way to avoid the warning without either compromising its efficacy
(i.e., causing false negatives for buggy code), or without delaying the folding
into memcpy to a point where the destination size is available (delaying the
folding is not a favorable solution).

That being said, the intended and recommended practice is to call strncat with
the amount of space remaining in the destination, e.g., like so:

  strncat (d, s, sizeof d - strlen (d) - 1);

In the test case in comment #0, strncat is being used to do two things: either
a) to append the initial portion of the string at cur without the terminating
nul and b) as a shortcut to to append the full nul-terminated string string
cur.  (a) is the intended use case, but (b) is not.  With that in mind,
changing the code to separate the two use cases like so avoids the warning:

  if (next)
strncat (plugin_name, cur, next - cur);
  else
strcpy (plugin_name, cur);

Another alternative is to use sprintf to combine all three calls into one:

  sprintf (plugin_name, "%s%.*s%s", prefix,
   next ? (int)(next - cur) : -1, cur,
   suffix);

I would suggest either of these also makes the code clearer.

[Bug other/82997] [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
Jakub's patch is 
.

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #7 from Fritz Reese  ---
*** Bug 83006 has been marked as a duplicate of this bug. ***

[Bug fortran/83006] [8 regression] gfortran.dg/pr78240.f90 fail

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Fritz Reese  ---
> Author: kargl
> Date: Wed Nov 15 18:14:14 2017
> New Revision: 254780
> 
> URL: https://gcc.gnu.org/viewcvs?rev=254780=gcc=rev
> Log:
> 2017-11-15  Steven G. Kargl  
> 
>   PR fortran/78240
>   gfortran.dg/pr78240.f90: Prune run-on errors.
> 
> Modified:
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gfortran.dg/pr78240.f90

Consequence of faulty test case from fortran/78240 in r254718, fixed in r254780

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

[Bug fortran/78240] ICE in match_clist_expr, at fortran/decl.c:728

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Nov 15 18:14:14 2017
New Revision: 254780

URL: https://gcc.gnu.org/viewcvs?rev=254780=gcc=rev
Log:
2017-11-15  Steven G. Kargl  

PR fortran/78240
gfortran.dg/pr78240.f90: Prune run-on errors.

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

[Bug other/82997] [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707

[dje at gcc dot gnu.org]

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

--- Comment #4 from David Edelsohn  ---
Andrey reports that this starts with r254707

[Bug other/82997] [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-15
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug other/82997] [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
*** Bug 83005 has been marked as a duplicate of this bug. ***

[Bug c++/83005] [8 regression] gcc.dg/cpp/macsyntx.c, gcc.dg/cpp/sysmac1.c fails

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from David Edelsohn  ---
Duplicate.

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

[Bug c++/83005] [8 regression] gcc.dg/cpp/macsyntx.c, gcc.dg/cpp/sysmac1.c fails

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|x86_64-*-*  |*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-15
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/82101] Uninitialized variable detection failed with variables in for loop

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Richard Biener from comment #1)
> Dup of some existing bug for sure.  t looks like initialized to GCC on the
> backedge:


Not any that I know.

> but that gets later optimistically propagated away (the variable is dead
> anyway)
> and thus the late pass warning about maybe-uninitialized doesn't get here.

Does the late pass ever warn for self-initialization?

void foo(int);
int main(){
for(int i = 0 ; i < 10 ; i ++){
int t=t;
foo(t);
}
return 0;
}

> Now what is special here is that the uninit value is on the loop entry edge
> so the early pass _could_ warn.

This seems the bug indeed.

void foo(void);
int main(){
for(int i = 0 ; i < 10 ; i ++){
int t=t;
foo();
}
return 0;
}

> It also looks like we could improve on scoping here when re-writing into SSA.
> t doesn't need a PHI node as the value is not live over the backedge.

missed-opt then?

[Bug target/83009] [8 regression] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-15
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Thanks, confirmed.

[Bug target/83009] New: [8 regression] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[clyon at gcc dot gnu.org]

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

Bug ID: 83009
   Summary: [8 regression] gcc.target/aarch64/store_v2vec_lanes.c
fails with -mabi=ilp32
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

As reported in https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01213.html ,
the new gcc.target/aarch64/store_v2vec_lanes.c fails when using -abi=ilp32.

Kyrill said:
My patch does indeed fail to generate the optimised sequence for -mabi=ilp32.
During combine it fails to match:
Failed to match this instruction:
(set (mem:V2DF (plus:DI (reg/v/f:DI 79 [ z ])
(const_int 32 [0x20])) [1 MEM[(v2df *)z_8(D) + 32B]+0 S16 A128])
(vec_concat:V2DF (reg:DF 81 [ y0 ])
(reg:DF 84 [ y1 ])))


but without the -mabi=ilp32 it does successfully match the equivalent

(set (mem:V2DF (plus:DI (reg:DI 1 x1 [ z ])
(const_int 32 [0x20])) [1 MEM[(v2df *)z_8(D) + 32B]+0 S16 A128])
(vec_concat:V2DF (reg:DF 81 [ y0 ])
(reg:DF 84 [ y1 ])))

The only difference is the index register being the hard reg x1.
There's probably some subtlety in aarch64_classify_address that I'll need to
dig into.

[Bug tree-optimization/82726] ICE in verify_ssa during GIMPLE pass: pcom

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Nov 15 16:20:21 2017
New Revision: 254778

URL: https://gcc.gnu.org/viewcvs?rev=254778=gcc=rev
Log:
PR tree-optimization/82726
PR tree-optimization/70754
* tree-predcom.c (order_drefs_by_pos): New function.
(combine_chains): Move code setting has_max_use_after to...
(try_combine_chains): ...here.  New parameter.  Sort combined chains
according to position information.
(tree_predictive_commoning_loop): Update call to above function.
(update_pos_for_combined_chains, pcom_stmt_dominates_stmt_p): New.

gcc/testsuite
* gcc.dg/tree-ssa/pr82726.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82726.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-predcom.c

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[manu at gcc dot gnu.org]

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

Bug 82958 Summary: uninitialized used warning missed (loop representation, 
do-while)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82958

   What|Removed |Added

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

[Bug tree-optimization/70754] [6 Regression] ICE during predictive commoning

[amker at gcc dot gnu.org]

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

--- Comment #19 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Nov 15 16:20:21 2017
New Revision: 254778

URL: https://gcc.gnu.org/viewcvs?rev=254778=gcc=rev
Log:
PR tree-optimization/82726
PR tree-optimization/70754
* tree-predcom.c (order_drefs_by_pos): New function.
(combine_chains): Move code setting has_max_use_after to...
(try_combine_chains): ...here.  New parameter.  Sort combined chains
according to position information.
(tree_predictive_commoning_loop): Update call to above function.
(update_pos_for_combined_chains, pcom_stmt_dominates_stmt_p): New.

gcc/testsuite
* gcc.dg/tree-ssa/pr82726.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82726.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-predcom.c

[Bug c/54554] fails to warn for uninitialized var within loop always taken at -O0

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||danielgutson at gmail dot com

--- Comment #10 from Manuel López-Ibáñez  ---
*** Bug 82958 has been marked as a duplicate of this bug. ***

[Bug middle-end/82958] uninitialized used warning missed (loop representation, do-while)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE
Summary|uninitialized used warning  |uninitialized used warning
   |missed when variable is |missed (loop
   |both in function argument   |representation, do-while)
   |and return value within a   |
   |loop|

--- Comment #1 from Manuel López-Ibáñez  ---
To detect uninitialized values within a loop, you need at least -O1, even if at
least one iteration of the loop is always executed.

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

[Bug tree-optimization/70754] [6 Regression] ICE during predictive commoning

[amker at gcc dot gnu.org]

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

--- Comment #18 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Nov 15 16:16:49 2017
New Revision: 254777

URL: https://gcc.gnu.org/viewcvs?rev=254777=gcc=rev
Log:
PR tree-optimization/82726
Revert
2017-01-23  Bin Cheng  

PR tree-optimization/70754
* tree-predcom.c (stmt_combining_refs): New parameter INSERT_BEFORE.
(reassociate_to_the_same_stmt): New parameter INSERT_BEFORE.  Insert
combined stmt before it if not NULL.
(combine_chains): Process refs reversely and compute dominance point
for root ref.

Revert
2017-02-23  Bin Cheng  

PR tree-optimization/79663
* tree-predcom.c (combine_chains): Process refs in reverse order
only for ZERO length chains, and add explaining comment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-predcom.c

[Bug tree-optimization/82726] ICE in verify_ssa during GIMPLE pass: pcom

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Nov 15 16:16:49 2017
New Revision: 254777

URL: https://gcc.gnu.org/viewcvs?rev=254777=gcc=rev
Log:
PR tree-optimization/82726
Revert
2017-01-23  Bin Cheng  

PR tree-optimization/70754
* tree-predcom.c (stmt_combining_refs): New parameter INSERT_BEFORE.
(reassociate_to_the_same_stmt): New parameter INSERT_BEFORE.  Insert
combined stmt before it if not NULL.
(combine_chains): Process refs reversely and compute dominance point
for root ref.

Revert
2017-02-23  Bin Cheng  

PR tree-optimization/79663
* tree-predcom.c (combine_chains): Process refs in reverse order
only for ZERO length chains, and add explaining comment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-predcom.c

[Bug tree-optimization/79663] [7 Regression] r244815 causes 10% regression for spec1k/172.mgrid on AArch64

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Nov 15 16:16:49 2017
New Revision: 254777

URL: https://gcc.gnu.org/viewcvs?rev=254777=gcc=rev
Log:
PR tree-optimization/82726
Revert
2017-01-23  Bin Cheng  

PR tree-optimization/70754
* tree-predcom.c (stmt_combining_refs): New parameter INSERT_BEFORE.
(reassociate_to_the_same_stmt): New parameter INSERT_BEFORE.  Insert
combined stmt before it if not NULL.
(combine_chains): Process refs reversely and compute dominance point
for root ref.

Revert
2017-02-23  Bin Cheng  

PR tree-optimization/79663
* tree-predcom.c (combine_chains): Process refs in reverse order
only for ZERO length chains, and add explaining comment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-predcom.c

[Bug c/82963] -Waddress too trigger happy

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Michal Hocko from comment #0)
> While the warning is correct and the given mask will always resolve to the
> success path of the ternary operator I really fail to see why we should warn
> about this fact. I really do not see any potential problem which could be
> caused by this fact.

The source code says:

c-common.c-3292-/* Common Ada/Pascal programmer's mistake.  */
c-common.c-3293-warning_at (location,
c-common.c-3294-OPT_Waddress,
c-common.c:3295:"the address of %qD will always
evaluate as %",

The work-around you found is probably the intended work-around. It would be
good to document this. Care to send a patch?
https://gcc.gnu.org/contribute.html#docchanges

> Moreover the warning itself is quite inconsistent. E.g. the following warns
> about the explicit  but not for n. So I believe this is more of a
> suboptimal warning implementation than real intention.

This is because the warning is given in the front-end, which does not know the
value of n. Not that it matters much, this is really trying to catch a typo,
not the actual value of a pointer.

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[sergey.shalnov at intel dot com]

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

--- Comment #1 from sergey.shalnov at intel dot com ---
Created attachment 42616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42616=edit
reproducer

[Bug target/83008] New: [performance] Is it better to avoid extra instructions in data passing between loops?

[sergey.shalnov at intel dot com]

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

Bug ID: 83008
   Summary: [performance] Is it better to avoid extra instructions
in data passing between loops?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergey.shalnov at intel dot com
  Target Milestone: ---

I found strange code generated by GCC-8.0/7.x with following command line
options:
-g -Ofast -march=skylake-avx512 -ftree-vectorize

There are not vectorized two loops. 
First one doesn’t vectorized because:
test.c:6:23: note: cost model: the vector iteration cost = 1488 divided by the
scalar iteration cost = 328 is greater or equal to the vectorization factor =
4.
test.c:6:23: note: not vectorized: vectorization not profitable.
test.c:6:23: note: not vectorized: vector version will never be profitable.

Second one doesn’t vectorized because:
test.c:20:23: note: step unknown.
test.c:20:23: note: reduction: not commutative/associative: sum_87 = (int) _61;
test.c:20:23: note: Unknown def-use cycle pattern.
test.c:20:23: note: Unsupported pattern.
test.c:20:23: note: not vectorized: unsupported use in stmt.
test.c:20:23: note: unexpected pattern.

If we look into asm we found strange method to passing data in “tmp” array
between loops:
…loop 1 body…
 13f:   41 8d 04 13 lea(%r11,%rdx,1),%eax
 143:   c5 f9 6e d8 vmovd  %eax,%xmm3
 147:   c5 e1 62 db vpunpckldq %xmm3,%xmm3,%xmm3
 14b:   c5 f9 62 c0 vpunpckldq %xmm0,%xmm0,%xmm0
 14f:   c5 f1 62 c9 vpunpckldq %xmm1,%xmm1,%xmm1
 153:   c5 e9 62 d2 vpunpckldq %xmm2,%xmm2,%xmm2
 157:   c5 e9 6c d2 vpunpcklqdq %xmm2,%xmm2,%xmm2
 15b:   c5 f1 6c c9 vpunpcklqdq %xmm1,%xmm1,%xmm1
 15f:   c5 f9 6c c0 vpunpcklqdq %xmm0,%xmm0,%xmm0
 163:   c5 e1 6c db vpunpcklqdq %xmm3,%xmm3,%xmm3
 167:   c4 e3 6d 38 c9 01   vinserti128 $0x1,%xmm1,%ymm2,%ymm1
 16d:   c4 e3 7d 38 c3 01   vinserti128 $0x1,%xmm3,%ymm0,%ymm0
 173:   62 f3 f5 48 3a c0 01vinserti64x4 $0x1,%ymm0,%zmm1,%zmm0
 17a:   62 f1 fd 48 7f 44 24vmovdqa64 %zmm0,-0x40(%rsp)
 181:   ff 
 182:   8b 54 24 e0 mov-0x20(%rsp),%edx
 186:   03 54 24 f0 add-0x10(%rsp),%edx
…loop 2 body…

if I'm not mistaken the algorithm looks like following:
1.  Do first loop and keep values in GPR
2.  Move these GPRs to XMMs
3.  Pack these XMMs into YMMs
4.  Pack these YMMs to ZMM
5.  Spill ZMM into stack
6.  Get values from stack to GPRs of the second loop

It might be better, from performance perspective, to pass values from first
loop directly to the second loop with GPRs (without all these vector
registers)?

The reproducer is:
 1  int test(unsigned char * input1, unsigned char * input2)
 2  {
 3  unsigned int tmp[4][4];
 4  unsigned int var0, var1, var2, var3;
 5  int sum = 0;
 6  for (int i = 0; i < 4; i++, input1 += 4, input2 += 4) {
 7  var0 = (input1[0] + input2[0]) + (input1[4] + input2[4]);
 8  var1 = (input1[1] + input2[1]) + (input1[5] + input2[5]);
 9  var2 = (input1[2] + input2[2]) + (input1[6] + input2[6]);
10  var3 = (input1[3] + input2[3]) + (input1[7] + input2[7]);
11  int inter0 = var0 + var1;
12  int inter1 = var0 + var1;
13  int inter2 = var2 + var3;
14  int inter3 = var2 + var3;
15  tmp[i][0] = inter0 + inter2;
16  tmp[i][2] = inter0 + inter2;
17  tmp[i][1] = inter1 + inter3;
18  tmp[i][3] = inter1 + inter3;
19  }
20  for (int i = 0; i < 4; i++) {
21  int inter0 = tmp[0][i] + tmp[1][i];
22  int inter1 = tmp[0][i] + tmp[1][i];
23  int inter2 = tmp[2][i] + tmp[3][i];
24  int inter3 = tmp[2][i] + tmp[3][i];
25  var0 = inter0 + inter2;
26  var2 = inter0 + inter2;
27  var1 = inter1 + inter3;
28  var3 = inter1 + inter3;
29  sum += var0 + var1 + var2 + var3;
30  }
31
32  return sum;
33  }

Sergey

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

[jb at gcc dot gnu.org]

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

--- Comment #7 from Janne Blomqvist  ---
(In reply to Thomas Koenig from comment #6)
> I cannot check at the moment, but I remember changing
> the KIND of mask arguments generated by the compiler to kind=1,
> to save memory. This is quite a few years ago, the PR
> to go with it escapes me at the moment.
> 
> Dunno if this helps.

I've seen code doing this, but only for the forall and where statements, which
aren't present in this testcase. Neither are masks in any other statement. Or
am I missing something?

[Bug fortran/83006] [8 regression] gfortran.dg/pr78240.f90 fail

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-15
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
See https://gcc.gnu.org/ml/fortran/2017-11/msg00078.html.

[Bug tree-optimization/83007] New: [8 Regression] -Wstringop-overflow false positive

[marxin at gcc dot gnu.org]

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

Bug ID: 83007
   Summary: [8 Regression] -Wstringop-overflow false positive
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Isolated from ./libgomp/target.c:

$ cat target.c
#include 
#include 

  char *prefix;
  char *suffix;
void a ()
{
  char *next = 0;
  char *cur;
  char *plugin_name;
  cur = "nvptx";
  plugin_name = (char *) malloc (1 + (next ? next - cur : strlen (cur))
 + strlen (prefix) + strlen (suffix));
  strcpy (plugin_name, prefix);
  strncat (plugin_name, cur, next ? next - cur : strlen (cur));
  strcat (plugin_name, suffix);
}

$ ./xgcc -B. target.c -O2 -Wall
target.c: In function ‘a’:
target.c:15:3: warning: ‘strncat’ specified bound 5 equals source length
[-Wstringop-overflow=]
   strncat (plugin_name, cur, next ? next - cur : strlen (cur));
   ^~~~

I think it's false positive as plugin_name is long enough.
Can you Martin please take a look?

[Bug fortran/83006] New: [8 regression] gfortran.dg/pr78240.f90 fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 83006
   Summary: [8 regression] gfortran.dg/pr78240.f90 fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r254718 triggers this:

spawn -ignore SIGHUP /work/gcc/testsuite/gfortran1/../../gfortran
-B/work/gcc/testsuite/gfortran1/../../
-B/work/x86_64-pc-linux-gnu/./libgfortran/
/source/gcc/testsuite/gfortran.dg/pr78240.f90 -fno-diagnostics-show-caret
-fdiagnostics-color=never -O -pedantic-errors -S -o pr78240.s
PASS: gfortran.dg/pr78240.f90   -O   (test for errors, line 11)
FAIL: gfortran.dg/pr78240.f90   -O  (test for excess errors)

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm

[Bug c++/60702] thread_local initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-15
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.2.0, 8.0

[Bug c++/83003] Using the detection idiom and void_t causes an error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-15
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Reduced:

template  class, class, class = void>
struct dtect1 { enum { value = 0 }; };

template  class TT, class T>
struct dtect1 { enum { value = 1 }; };

template  struct Zod  { using type = double; };
template <>struct Zod {  };
template  using Zod_t = typename Zod::type;

static_assert(!dtect1::value, ""); // (1)

Zod_t z1; // a double
Zod_t   z2; // !!

[Bug other/82997] [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707

[andrey.y.guskov at intel dot com]

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

Andrey Guskov  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #1 from Andrey Guskov  ---
Also seeing this: pr83005
Shall I mark my report as a duplicate?

[Bug c++/83005] New: [8 regression] gcc.dg/cpp/macsyntx.c, gcc.dg/cpp/sysmac1.c fails

[andrey.y.guskov at intel dot com]

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

Bug ID: 83005
   Summary: [8 regression] gcc.dg/cpp/macsyntx.c,
gcc.dg/cpp/sysmac1.c fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r254707 triggers these:

...
PASS: gcc.dg/cpp/macsyntx.c  (test for errors, line 46)
PASS: gcc.dg/cpp/macsyntx.c  (test for errors, line 50)
PASS: gcc.dg/cpp/macsyntx.c  (test for errors, line 51)
FAIL: gcc.dg/cpp/macsyntx.c  (test for warnings, line 54)

...
spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.dg/cpp/sysmac1.c -fno-diagnostics-show-caret
-fdiagnostics-color=never -std=gnu99 -pedantic -Wtraditional
-ftrack-macro-expansion=0 -E -o sysmac1.i
PASS: gcc.dg/cpp/sysmac1.c  (test for warnings, line 15)
PASS: gcc.dg/cpp/sysmac1.c  (test for warnings, line 17)
PASS: gcc.dg/cpp/sysmac1.c  (test for bogus messages, line 19)
PASS: gcc.dg/cpp/sysmac1.c  (test for warnings, line 22)
PASS: gcc.dg/cpp/sysmac1.c  (test for bogus messages, line 23)
FAIL: gcc.dg/cpp/sysmac1.c  (test for warnings, line 25)

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm

[Bug target/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens.fr]

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

--- Comment #38 from Dominique d'Humieres  ---
> True, I guess I can do that, too...

Well, let the assignee do it if (s)he does not accept the assignment.

[Bug middle-end/83004] New: [8 regression] gcc.dg/vect/pr81136.c fail

[andrey.y.guskov at intel dot com]

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

Bug ID: 83004
   Summary: [8 regression] gcc.dg/vect/pr81136.c fail
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

r254589 triggers this:

spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.dg/vect/pr81136.c
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-fdiagnostics-color=never -msse2 -ftree-vectorize -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -S -o pr81136.s
PASS: gcc.dg/vect/pr81136.c (test for excess errors)
FAIL: gcc.dg/vect/pr81136.c scan-tree-dump-not vect "Unknown misalignment"

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=haswell --with-cpu=haswell

[Bug target/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target||i686-pc-cygwin
  Component|fortran |target

--- Comment #37 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #36)
> > Well... if I can't confirm it myself, and I can't put it in SUSPENDED,
> > and I can't mark it as RESOLVED... I guess I'll assign it to you then.
> 
> An alternative would be to move the component from 'fortran' to 'target'.

True, I guess I can do that, too...

[Bug c++/83003] Using the detection idiom and void_t causes an error

[pkeir at outlook dot com]

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

Paul Keir  changed:

   What|Removed |Added

 CC||pkeir at outlook dot com

--- Comment #1 from Paul Keir  ---
Created attachment 42615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42615=edit
The code described in the bug

[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
URL||https://bugs.kde.org/show_b
   ||ug.cgi?id=386945
 Resolution|--- |MOVED

--- Comment #16 from Markus Trippelsdorf  ---
Not a compiler bug. Moved to valgrind bugzilla:
https://bugs.kde.org/show_bug.cgi?id=386945

[Bug c++/81574] ICE on valid C++14 code: in canonicalize_component_ref, at gimplify.c:2481

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Resolved r254768.

[Bug c++/81574] ICE on valid C++14 code: in canonicalize_component_ref, at gimplify.c:2481

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Wed Nov 15 13:18:09 2017
New Revision: 254768

URL: https://gcc.gnu.org/viewcvs?rev=254768=gcc=rev
Log:
[PR c++/81574] lambda capture of function reference

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01200.html
PR c++/81574
* lambda.c (lambda_capture_field_type): Function references are
always catured by reference.

PR c++/81574
* g++.dg/cpp1y/pr81574.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr81574.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/82985] [7 Regression] ICC: in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1722

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #20 from Markus Trippelsdorf  ---
Fixed. Thanks.

[Bug tree-optimization/82985] [7 Regression] ICC: in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1722

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 15 12:53:21 2017
New Revision: 254767

URL: https://gcc.gnu.org/viewcvs?rev=254767=gcc=rev
Log:
2017-11-15  Richard Biener  

PR tree-optimization/82985
* g++.dg/torture/pr82985.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr82985.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/81790] [8 Regression] ICE in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1738

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 15 12:50:39 2017
New Revision: 254766

URL: https://gcc.gnu.org/viewcvs?rev=254766=gcc=rev
Log:
2017-11-15  Richard Biener  

PR tree-optimization/82985
Backport from mainline
2017-08-15  Richard Biener  

PR tree-optimization/81790
* tree-ssa-sccvn.c (vn_lookup_simplify_result): Handle both
CONSTRUCTORs from simplifying and VN.

* gcc.dg/torture/pr81790.c: New testcase.
* g++.dg/torture/pr82985.C: Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr82985.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr81790.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/82985] [7 Regression] ICC: in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1722

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Wed Nov 15 12:50:39 2017
New Revision: 254766

URL: https://gcc.gnu.org/viewcvs?rev=254766=gcc=rev
Log:
2017-11-15  Richard Biener  

PR tree-optimization/82985
Backport from mainline
2017-08-15  Richard Biener  

PR tree-optimization/81790
* tree-ssa-sccvn.c (vn_lookup_simplify_result): Handle both
CONSTRUCTORs from simplifying and VN.

* gcc.dg/torture/pr81790.c: New testcase.
* g++.dg/torture/pr82985.C: Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr82985.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr81790.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug target/82961] ICE in dwarf2out.c: deferred_asm_name != NULL

[vries at gcc dot gnu.org]

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

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

[Bug target/82990] Update the default -mzeroupper setting

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Sebastian Peryt from comment #5)
> (In reply to H.J. Lu from comment #3)
> > Created attachment 42611 [details]
> > A better patch
> > 
> > Sebastian, please take a look.
> LGTM

Can you run the full test with it?

[Bug target/82941] Missing vzeroupper with -march=skylake-avx512 -O2

[speryt at gcc dot gnu.org]

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

--- Comment #2 from speryt at gcc dot gnu.org ---
Author: speryt
Date: Wed Nov 15 12:27:31 2017
New Revision: 254763

URL: https://gcc.gnu.org/viewcvs?rev=254763=gcc=rev
Log:
Fix PR82941 and PR82942 by adding proper vzeroupper generation on SKX. 

2017-11-15  Sebastian Peryt  

gcc/

PR target/82941
PR target/82942
* config/i386/i386.c (pass_insert_vzeroupper): Modify gate condition
to return true on Xeon and not on Xeon Phi.
(ix86_check_avx256_register): Changed to ...
(ix86_check_avx_upper_register): ... this. Add extra check for
VALID_AVX512F_REG_OR_XI_MODE.
(ix86_avx_u128_mode_needed): Changed
ix86_check_avx256_register to ix86_check_avx_upper_register.
(ix86_check_avx256_stores): Changed to ...
(ix86_check_avx_upper_stores): ... this. Changed
ix86_check_avx256_register to ix86_check_avx_upper_register.
(ix86_avx_u128_mode_after): Changed
avx_reg256_found to avx_upper_reg_found. Changed
ix86_check_avx256_stores to ix86_check_avx_upper_stores.
(ix86_avx_u128_mode_entry): Changed
ix86_check_avx256_register to ix86_check_avx_upper_register.
(ix86_avx_u128_mode_exit): Ditto.
* config/i386/i386.h: (host_detect_local_cpu): New define.

2017-11-15  Sebastian Peryt  

gcc/testsuite/

PR target/82941
PR target/82942
* gcc.target/i386/pr82941-1.c: New test.
* gcc.target/i386/pr82941-2.c: New test.
* gcc.target/i386/pr82942-1.c: New test.
* gcc.target/i386/pr82942-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr82941-1.c
trunk/gcc/testsuite/gcc.target/i386/pr82941-2.c
trunk/gcc/testsuite/gcc.target/i386/pr82942-1.c
trunk/gcc/testsuite/gcc.target/i386/pr82942-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog

[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2

[speryt at gcc dot gnu.org]

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

--- Comment #7 from speryt at gcc dot gnu.org ---
Author: speryt
Date: Wed Nov 15 12:27:31 2017
New Revision: 254763

URL: https://gcc.gnu.org/viewcvs?rev=254763=gcc=rev
Log:
Fix PR82941 and PR82942 by adding proper vzeroupper generation on SKX. 

2017-11-15  Sebastian Peryt  

gcc/

PR target/82941
PR target/82942
* config/i386/i386.c (pass_insert_vzeroupper): Modify gate condition
to return true on Xeon and not on Xeon Phi.
(ix86_check_avx256_register): Changed to ...
(ix86_check_avx_upper_register): ... this. Add extra check for
VALID_AVX512F_REG_OR_XI_MODE.
(ix86_avx_u128_mode_needed): Changed
ix86_check_avx256_register to ix86_check_avx_upper_register.
(ix86_check_avx256_stores): Changed to ...
(ix86_check_avx_upper_stores): ... this. Changed
ix86_check_avx256_register to ix86_check_avx_upper_register.
(ix86_avx_u128_mode_after): Changed
avx_reg256_found to avx_upper_reg_found. Changed
ix86_check_avx256_stores to ix86_check_avx_upper_stores.
(ix86_avx_u128_mode_entry): Changed
ix86_check_avx256_register to ix86_check_avx_upper_register.
(ix86_avx_u128_mode_exit): Ditto.
* config/i386/i386.h: (host_detect_local_cpu): New define.

2017-11-15  Sebastian Peryt  

gcc/testsuite/

PR target/82941
PR target/82942
* gcc.target/i386/pr82941-1.c: New test.
* gcc.target/i386/pr82941-2.c: New test.
* gcc.target/i386/pr82942-1.c: New test.
* gcc.target/i386/pr82942-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr82941-1.c
trunk/gcc/testsuite/gcc.target/i386/pr82941-2.c
trunk/gcc/testsuite/gcc.target/i386/pr82942-1.c
trunk/gcc/testsuite/gcc.target/i386/pr82942-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig  ---
I cannot check at the moment, but I remember changing
the KIND of mask arguments generated by the compiler to kind=1,
to save memory. This is quite a few years ago, the PR
to go with it escapes me at the moment.

Dunno if this helps.

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens.fr]

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

--- Comment #36 from Dominique d'Humieres  ---
> Well... if I can't confirm it myself, and I can't put it in SUSPENDED,
> and I can't mark it as RESOLVED... I guess I'll assign it to you then.

An alternative would be to move the component from 'fortran' to 'target'.

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

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
The ICE for the test in comment 0 disappeared at r254605.

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |urbanjost at comcast 
dot net

--- Comment #35 from Eric Gallager  ---
(In reply to urbanjost from comment #34)
> It still occurs with Cygwin 2.8.2, which comes with gfortran 5.4.0, which is
> the latest version of CygWin, if that is of any help.
> 
> -Original Message-
> From: dominiq at lps dot ens.fr [mailto:gcc-bugzi...@gcc.gnu.org] 
> Sent: Sunday, August 13, 2017 6:00 AM
> To: urbanj...@comcast.net
> Subject: [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not
> loading from library
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
> 
> --- Comment #34 from Dominique d'Humieres  ---
> > So... what should we do with this bug then? I'm trying to move it out 
> > of the WAITING queue. Change to SUSPENDED?
> 
> I am afraid that SUSPENDED is some kind of black hole for problems waiting
> committee clarification. Here we are still waiting an answer from CygWin
> users if it is still present with recent releases.
> 
> --
> You are receiving this mail because:
> You reported the bug.

Well... if I can't confirm it myself, and I can't put it in SUSPENDED, and I
can't mark it as RESOLVED... I guess I'll assign it to you then.

[Bug debug/82155] [7 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:21655

[derodat at adacore dot com]

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

Pierre-Marie de Rodat  changed:

   What|Removed |Added

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

--- Comment #9 from Pierre-Marie de Rodat  ---
Fix is on trunk and I just merged it in the gcc-7 branch. I’ve left the target
milestone to 7.3 even though 7.4 is available since according to
https://gcc.gnu.org/gcc-7/, the last release was 7.2. Hoping I got it right!

[Bug other/46633] [meta-bug] frontends use BITS_PER_UNIT when they mean TYPE_PRECISION (char_type_node)

[egallager at gcc dot gnu.org]

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

Bug 46634 Summary: cp/typeck2.c: uses BITS_PER_UNIT in lieu of TYPE_PRECISION 
(char_type_node)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46634

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug c++/46634] cp/typeck2.c: uses BITS_PER_UNIT in lieu of TYPE_PRECISION (char_type_node)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> (In reply to Jorn Wolfgang Rennecke from comment #0)
> > 
> 
> Um... bug report missing? Would help to have something more than the title...

No response; closing.

[Bug debug/82155] [7 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.c:21655

[pmderodat at gcc dot gnu.org]

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

--- Comment #8 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Wed Nov 15 11:54:11 2017
New Revision: 254761

URL: https://gcc.gnu.org/viewcvs?rev=254761=gcc=rev
Log:
[PATCH] [PR82155] Fix crash in dwarf2out_abstract_function

Backport from mainline (r253147):

This patch is an attempt to fix the crash reported in PR82155.

When generating a C++ class method for a class that is itself nested in
a class method, dwarf2out_early_global_decl currently leaves the
existing context DIE as it is if it already exists.  However, it is
possible that this call happens at a point where this context DIE is
just a declaration that is itself not located in its own context.

From there, if dwarf2out_early_global_decl is not called on any of the
FUNCTION_DECL in the context chain, DIEs will be left badly scoped and
some (such as the nested method) will be removed by the type pruning
machinery.  As a consequence, dwarf2out_abstract_function will will
crash when called on the corresponding DECL because it asserts that the
DECL has a DIE.

This patch fixes this crash making dwarf2out_early_global_decl process
context DIEs the same way we process abstract origins for FUNCTION_DECL:
if the corresponding DIE exists but is only a declaration, call
dwarf2out_decl anyway on it so that it is turned into a more complete
DIE and so that it is relocated in the proper context.

Bootstrapped and regtested on x86_64-linux.

gcc/

PR debug/82155
* dwarf2out.c (dwarf2out_early_global_decl): Call dwarf2out_decl
on the FUNCTION_DECL function context if it has a DIE that is a
declaration.

gcc/testsuite/

* g++.dg/pr82155.C: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/pr82155.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dwarf2out.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug ada/83002] New: Missing finalization of generic package body

[demoonlit at panathenaia dot halfmoon.jp]

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

Bug ID: 83002
   Summary: Missing finalization of generic package body
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: demoonlit at panathenaia dot halfmoon.jp
  Target Milestone: ---

Created attachment 42613
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42613=edit
bug triggering source code

Hello.

The finalizer of package body (postfixed "__finalize_body") for controlled
object is not generated when it is generic package (and its spec does not need
finalizer ?).

See the attached file and run. I've expected for getting "OK" outputted by the
finalizer, but did not. And it works correctly if the controlled object
declaration is moved to its spec.

This bug also appeared with GNAT-GPL 2017.


with x;
generic
package y is
   pragma elaborate_body;
end y;

package body y is
   object : x.t; -- this controlled object would not be finalized
end y;

[Bug fortran/82979] [PDT] [F2003] [ice-on-invalid] ICE (segfault) on invalid type-param-name-list in PDT declaration

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-15
 Ever confirmed|0   |1

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

My instrumented gfortran gives

Error: Expected parameter list in type declaration at (1)
=
==77480==ERROR: AddressSanitizer: heap-use-after-free on address 0x61302f00
at pc 0x0001004995e8 bp 0x7ffeefbfe670 sp 0x7ffeefbfe668
READ of size 8 at 0x61302f00 thread T0
#0 0x1004995e7 in gfc_restore_last_undo_checkpoint() symbol.c:3647
#1 0x10049aa2c in gfc_undo_symbols() symbol.c:3727
#2 0x1002fefd5 in reject_statement() parse.c:2546
#3 0x1002ff11d in match_word(char const*, match (*)(), locus*) parse.c:70
#4 0x10030cdd0 in decode_statement() parse.c:565
#5 0x10030e091 in next_free() parse.c:1225
#6 0x10030ea5e in next_statement() parse.c:1457
#7 0x10031e6f4 in gfc_parse_file() parse.c:6160
#8 0x1004d36b3 in gfc_be_parse_file() f95-lang.c:204
#9 0x1052de1b0 in compile_file() toplev.c:454
#10 0x1052e857d in do_compile() toplev.c:2059
#11 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#12 0x1075e2a87 in main main.c:39
#13 0x7fff5ec55144 in start (libdyld.dylib:x86_64+0x1144)

0x61302f00 is located 320 bytes inside of 336-byte region
[0x61302dc0,0x61302f10)
freed by thread T0 here:
#0 0x155318460 in wrap_free.part.0 sanitizer_malloc_mac.inc:142
#1 0x100489adb in gfc_free_symbol(gfc_symbol*) symbol.c:3061
#2 0x100489e27 in gfc_release_symbol(gfc_symbol*) symbol.c:3088
#3 0x10048a2a6 in free_sym_tree(gfc_symtree*) symbol.c:3890
#4 0x10048905b in gfc_free_namespace(gfc_namespace*) symbol.c:4045
#5 0x100489a6c in gfc_free_symbol(gfc_symbol*) symbol.c:3054
#6 0x100489e27 in gfc_release_symbol(gfc_symbol*) symbol.c:3088
#7 0x10049a1c7 in gfc_restore_last_undo_checkpoint() symbol.c:3696
#8 0x10049aa2c in gfc_undo_symbols() symbol.c:3727
#9 0x1002fefd5 in reject_statement() parse.c:2546
#10 0x1002ff11d in match_word(char const*, match (*)(), locus*) parse.c:70
#11 0x10030cdd0 in decode_statement() parse.c:565
#12 0x10030e091 in next_free() parse.c:1225
#13 0x10030ea5e in next_statement() parse.c:1457
#14 0x10031e6f4 in gfc_parse_file() parse.c:6160
#15 0x1004d36b3 in gfc_be_parse_file() f95-lang.c:204
#16 0x1052de1b0 in compile_file() toplev.c:454
#17 0x1052e857d in do_compile() toplev.c:2059
#18 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#19 0x1075e2a87 in main main.c:39
#20 0x7fff5ec55144 in start (libdyld.dylib:x86_64+0x1144)

previously allocated by thread T0 here:
#0 0x155317aac in wrap_calloc sanitizer_malloc_mac.inc:153
#1 0x10746b354 in xcalloc xmalloc.c:162
#2 0x100480eb1 in gfc_new_symbol(char const*, gfc_namespace*) symbol.c:3099
#3 0x1004833c0 in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3348
#4 0x100484a01 in gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**)
symbol.c:3401
#5 0x1000b162d in gfc_match_formal_arglist(gfc_symbol*, int, int, bool)
decl.c:5959
#6 0x1000cd42e in gfc_match_derived_decl() decl.c:9829
#7 0x1002ff09b in match_word(char const*, match (*)(), locus*) parse.c:65
#8 0x10030cdd0 in decode_statement() parse.c:565
#9 0x10030e091 in next_free() parse.c:1225
#10 0x10030ea5e in next_statement() parse.c:1457
#11 0x10031e6f4 in gfc_parse_file() parse.c:6160
#14 0x1052e857d in do_compile() toplev.c:2059
#15 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#16 0x1075e2a87 in main main.c:39
#17 0x7fff5ec55144 in start (libdyld.dylib:x86_64+0x1144)

SUMMARY: AddressSanitizer: heap-use-after-free symbol.c:3647 in
gfc_restore_last_undo_checkpoint()
Shadow bytes around the buggy address:
  0x1c260590: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2605a0: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x1c2605b0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x1c2605c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2605d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x1c2605e0:[fd]fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c2605f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c260600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c260610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c260620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c260630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application 

[Bug fortran/82969] [6/7/8 Regression] ICE in gfc_class_vptr_get, at fortran/trans-expr.c:211

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||4.6.4
Summary|ICE in gfc_class_vptr_get,  |[6/7/8 Regression] ICE in
   |at fortran/trans-expr.c:211 |gfc_class_vptr_get, at
   ||fortran/trans-expr.c:211
  Known to fail||4.7.3, 4.8.5, 4.9.3, 5.5.0,
   ||6.4.0, 7.2.0, 8.0

--- Comment #3 from Dominique d'Humieres  ---
> Confirmed, started with GCC 4.7.0.

Thus it is a regression. The change occurred between revisions r182107
(2011-12-08, compiles) and r183001 (2012-01-09, ICE).

It is related to/a duplicate of pr66679 (same ICE). pr79072 gives a similar
ICE, but in a different location: fortran/trans-expr.c:226. Both locations
correspond to a call to gfc_advance_chain.

[Bug target/82990] Update the default -mzeroupper setting

[sebastian.peryt at intel dot com]

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

--- Comment #5 from Sebastian Peryt  ---
(In reply to H.J. Lu from comment #3)
> Created attachment 42611 [details]
> A better patch
> 
> Sebastian, please take a look.
LGTM

[Bug tree-optimization/82985] [7 Regression] ICC: in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1722

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #17 from Richard Biener  ---
Looks like a dup of PR81790.  Will backport the fix.

[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist  ---
So the problem is the logical(kind=1) one, it should be the same type as the
LHS.

It seems it originates from (from .003t.original):

logical(kind=4) D.3603;
...
D.3603 = (struct test_typ[0:] * restrict) conc.data == 0B;

Then in the .177t.thread3 dump this has become:

_15 = _34 == _6;

Then finally in the 178t.dom3 dump with -fdump-tree-all-details (this is the
pass where it ICE's):

Optimizing statement _15 = _34 == _6;
  Replaced '_34' with variable '_13'
  Replaced '_6' with constant ''
gimple_simplified to _15 = 0;
  Folded to: _15 = 0;
LKUP STMT _15 = 0
 ASGN _15 = 0


I have gone through uses of EQ_EXPR (and NE_EXPR, and boolean_type_node, and
boolean_true_node, and boolean_false_node) in the frontend and I haven't found
a place where it would use boolean_type_node (i.e. logical(kind=1) instead of
logical_type_node (logical(kind=4)). So at the moment I'm a bit stuck. Does the
above give you any kind of hint what the problem might be?

[Bug tree-optimization/82985] [7 Regression] ICC: in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1722

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |7.3

[Bug fortran/82996] ICE and segfault with derived type finalization

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
I see the problems on all gfortran supporting finalization (4.9 up to trunk
8.0), except the ICEs that are no longer present on recent trunk. The change
occurred between revisions r247817 (2017-05-09, ICE) and r248367 (2017-05-23,
compiles). In top of that the code in comment 2 executes without segfault.

[Bug fortran/82923] Automatic allocation of deferred length character using function result

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Ha! That's an 'amusing' one. I too am surprised that there is no duplicate.

I'll take it.

Paul

[Bug target/82961] ICE in dwarf2out.c: deferred_asm_name != NULL

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rupp at gnat dot com,
   ||sebastian.huber@embedded-br
   ||ains.de
  Known to fail||8.0

--- Comment #5 from Martin Liška  ---
Confirmed, following simple test-case is sufficient:

$ cat ice.i
int a;

Also ICEs with merge base of GCC 7 branch.
I'm CCing VMS maintainers.

[Bug target/82961] ICE in dwarf2out.c: deferred_asm_name != NULL

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
So, deferred_asm_name is cleared by dwarf2out_early_finish, which is then
checked by the assert in dwarf2out_finish.

vmsdbgout_finish calls dwarf2out_finish (which checks the assert), but
dwarf2out_early_finish is never called.

The vms debug hooks have vmsdbgout_finish but no vmsdbgout_early_finish:
...
const struct gcc_debug_hooks vmsdbg_debug_hooks
= {vmsdbgout_init,
   vmsdbgout_finish,
   debug_nothing_charstar, /* early_finish */
...

[Bug fortran/82814] ICE from submodule character function

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
I'll take it.

Paul

[Bug target/82981] [7/8 Regression] unnecessary __multi3 call for mips64r6 linux kernel

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 15 09:01:42 2017
New Revision: 254758

URL: https://gcc.gnu.org/viewcvs?rev=254758=gcc=rev
Log:
PR target/82981
* internal-fn.c: Include gimple-ssa.h, tree-phinodes.h and
ssa-iterators.h.
(can_widen_mult_without_libcall): New function.
(expand_mul_overflow): If only checking unsigned mul overflow,
not result, and can do efficiently MULT_HIGHPART_EXPR, emit that.
Don't use WIDEN_MULT_EXPR if it would involve a libcall, unless
no other way works.  Add MULT_HIGHPART_EXPR + MULT_EXPR support.
(expand_DIVMOD): Formatting fix.
* expmed.h (expand_mult): Add NO_LIBCALL argument.
* expmed.c (expand_mult): Likewise.  Use OPTAB_WIDEN rather
than OPTAB_LIB_WIDEN if NO_LIBCALL is true, and allow it to fail.

* gcc.target/mips/pr82981.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/mips/pr82981.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
trunk/gcc/expmed.h
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog

[Bug target/82961] ICE in dwarf2out.c: deferred_asm_name != NULL

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug target/82961] ICE in dwarf2out.c: deferred_asm_name != NULL

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Created attachment 42612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42612=edit
lshrdi3.c

To reproduce:
...
$ gcc -mcpu=ev6 -mieee -mpointer-size=64 -g -O2 -fbuilding-libgcc
-fno-stack-protector -mpointer-size=64 -S lshrdi3.c
src/libgcc/libgcc2.c:427:1: internal compiler error: in dwarf2out_finish, at
dwarf2out.c:29826
 }
 ^
0xa64e1b dwarf2out_finish
src/gcc/dwarf2out.c:29826
0x1476ede vmsdbgout_finish
src/gcc/vmsdbgout.c:1569
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

[Bug other/62002] -fcilkplus switch breaks format attribute.

[vincenzo.romano at notorand dot it]

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

Vincenzo Romano  changed:

   What|Removed |Added

 CC||vincenzo.romano at notorand 
dot it

--- Comment #7 from Vincenzo Romano  ---
The original code snippet is wrong.

It should read

void bar(char const *, ...) __attribute__((__format__(__printf__, 1, 2)));

instead of

void bar(char const *, ...) __attribute__((__format__(__printf__, 2, 3)));

Accordingly to the documentation at

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

The second __format__() argument is the 1-based position of the formatting
string, while the third one is the 1-based position of the first argument to be
checked.

[Bug tree-optimization/82977] [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 15 08:40:32 2017
New Revision: 254757

URL: https://gcc.gnu.org/viewcvs?rev=254757=gcc=rev
Log:
PR tree-optimization/82977
* tree-ssa-strlen.c (strlen_optimize_stmt): Pass a reference to a copy
constructed temporary to strlen_to_stridx.put.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug c/82999] a func has two entrys: one inlined, another is normal

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Richard Biener  ---
Just use -fno-partial-inlining if you don't like it.

[Bug other/82997] [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/82991] memcpy and strcpy return value can be assumed to be equal to first argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-15
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #1)
> GCC tracks that fact, see gimple_call_return_flags ERF_RETURNS_ARG and
> ERF_RETURN_ARG_MASK to say which argument it is.
> From what I can see, it is used during aliasing and vrp (in the latter case
> only whether it is non-NULL or not).  So it is just a matter of using it in
> further optimizations.  But it needs to be used with care.
> Trying to optimize:
>   return strcpy (x, y);
> as
>   strcpy (x, y);
>   return x;
> is not a good idea, it would make it not tail-call optimizable, and in many
> cases even for RA purposes it is cheaper to read the value from the return
> register rather than saving it in call saved register and restoring from
> there, etc. Which is why it is not that strightforward to say do it in SCCVN.

Yes, I've done it in SCCVN (I belive there's a dup of this PR), also to the
effect to transform

  x = strcpy (y, z);
  foo (y);

to

  x = strcpy (y, z);
  foo (x);

I can dig up the patch, it must be sitting somewhere on my disk...