[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #2 from Eric Gallager  ---
maybe try putting #pragma GCC system_header in your headers? idk

[Bug c/81453] relational expression involving null pointer not diagnosed with -Wall

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
The name -Wordered-pointer-comparison was suggested for this warning here: 
https://gcc.gnu.org/ml/gcc-patches/2007-01/msg00608.html

[Bug c++/68897] No option to disable just "warning: enumeral and non-enumeral type in conditional expression"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #1)
> You just need to come up with a good name and implement a patch like the
> ones shown in PR7651. Finding a good name is probably the hardest part. :)
> 
> 
> See also https://gcc.gnu.org/ml/gcc/2007-01/msg00391.html

>From that thread, it seems like the agreement was to put it under -Wconversion:
https://gcc.gnu.org/ml/gcc/2007-01/msg00437.html

[Bug c++/86375] Lambda call in template parameter causes compile time error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Actually, we seem to have a pretty much identical testcase (e.g.
lambda-uneval7.C), so I'll just mark it as fixed.

Fixed by r266056, for the record.

[Bug c++/91120] broken template instantiation for std::string_view values

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I'm not sure if this is valid.  http://eel.is/c++draft/temp.arg.nontype#4 says
A string literal ([lex.string]) is not an acceptable template-argument for a
template-parameter of non-class type.
but given the sv suffix, the argument should be of type
basic_string_view, and thus valid?

[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

[aacid at kde dot org]

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

--- Comment #1 from Albert Astals Cid  ---
This is with gcc version 9.1.0

[Bug c++/91187] New: Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

[aacid at kde dot org]

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

Bug ID: 91187
   Summary: Is it possible to make -Wzero-as-null-pointer-constant
learn about extern "C"?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aacid at kde dot org
  Target Milestone: ---

This is more a wish than a bug report, sorry if this is not the proper place to
talk about this.

It also contains two scenarios that for my "i know nothing about compilers"
seem to be the same thing, but if you prefer me to close this and file two
different issues i'm happy to also do that :)

I like to have -Wzero-as-null-pointer-constant enabled, but when interfacing
with C libraries it's painful because it says "you're using a 0 when you should
use nullptr", but in some cases "you can't".


Scenario 1:

 main.cpp 
extern "C" {
#include "myzlib.h"
}

int main(int argc, char **argv)
{
void *bla = Z_NULL;
}

 myzlib.h 
#define Z_NULL 0

I guess you could argue here that one could stop using Z_NULL and use nullptr
directly but given that Z_NULL is what the documentation says to use, it would
be cool if one could see that Z_NULL is defined as 0 inside an include wrapped
by extern "C" and not give a warning


Scenario 2:

 main.cpp 
extern "C" {
#include "clib.h"
}

int main(int argc, char **argv)
{
simple(3);
}

 clib.h 
typedef struct {
int value;
int *something;
} MyStruct;

#define simple(x) MyStruct s; s.value = x; s.something = 0;


In this case the use of 0 as nullptr is totally inside the extern "C" header,
so there's nothing one can do to not have a warning.

[Bug c++/91184] memory leak with enable_shared_from_this and pthread

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed in r273167.

[Bug lto/91186] gcc-9.1.0 fails to to fins a .symver symbol

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
There are known issues with top-level inline-asm and LTO and you are running
into one of those.


FUSE_SYMVER(".symver fuse_setup_compat2,__fuse_setup@");
FUSE_SYMVER(".symver fuse_setup_compat22,fuse_setup@FUSE_2.2");
FUSE_SYMVER(".symver fuse_teardown,__fuse_teardown@");
FUSE_SYMVER(".symver fuse_main_compat2,fuse_main@");
FUSE_SYMVER(".symver fuse_main_real_compat22,fuse_main_real@FUSE_2.2");

[Bug middle-end/61577] [4.9.0] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #70 from EML  ---
Created attachment 46606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46606=edit
islower pre-processed code (-E flag)

Attached the pre-processed code from -E

[Bug regression/91185] -Og miscompiles code causing runtime segfault

[david.bolvansky at gmail dot com]

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

Dávid Bolvanský  changed:

   What|Removed |Added

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

--- Comment #2 from Dávid Bolvanský  ---
Ok, it seems this is not a miscompilation. Just -O1 and higher hides bug in the
code (no segfault).

[Bug regression/91185] -Og miscompiles code causing runtime segfault

[david.bolvansky at gmail dot com]

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

--- Comment #1 from Dávid Bolvanský  ---
(gdb) r bw
Starting program: /home/xbolva00/IFJ16/src/ifj16c bw

Program received signal SIGSEGV, Segmentation fault.
0xeac5 in eval (op=0x55768b80) at interpret.c:37
37  tVar *a = op->offset + frame_stack.top->frame->local;
(gdb) disassemble
Dump of assembler code for function eval:
   0xeab9 <+0>: test   %rdi,%rdi
   0xeabc <+3>: je 0xeaf4 
   0xeabe <+5>: mov0x205d8b(%rip),%rax#
0x55764850 
=> 0xeac5 <+12>:mov(%rax),%rsi
   0xeac8 <+15>:mov0x10(%rdi),%edx
   0xeacb <+18>:movslq %edx,%rax

[Bug lto/91186] gcc-9.1.0 fails to to fins a .symver symbol

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 46605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46605=edit
gcc-lto-partition-bug.tar.gz

[Bug lto/91186] New: gcc-9.1.0 fails to to fins a .symver symbol

[slyfox at inbox dot ru]

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

Bug ID: 91186
   Summary: gcc-9.1.0 fails to to fins a .symver symbol
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The bug is originally discovered as a fuse-2.9.9 build failure on CFLAGS="-O2
-flto" LDFLAGS="-O2 -flto -Wl,--no-undefined": https://bugs.gentoo.org/663518

I failed to extract minimal example off fuse. Attaching self-contained source
tarball with a simple build script.

Script tries to build with lto in 3 modes:

  $ ./bug2.bash 
  Building -O1
  Building -flto -O1 --param lto-partitions=1
  Building -flto -O1 --param lto-partitions=2
 
/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/libbug.so.IbcCw4.ltrans0.ltrans.o: in function `mt_chan_receive':
  :(.text+0x9f0d): undefined reference to `__fuse_read_cmd@'
  collect2: error: ld returned 1 exit status

Note: only --param lto-partitions=2 triggers build failure.

It's an x86_64-pc-linux-gnu gcc-9.1.1 / binutils-2.32.

[Bug regression/91185] New: -Og miscompiles code causing runtime segfault

[david.bolvansky at gmail dot com]

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

Bug ID: 91185
   Summary: -Og miscompiles code causing runtime segfault
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.bolvansky at gmail dot com
  Target Milestone: ---

tVar *eval(tVar *op)
{
if (unlikely(op == NULL))
return NULL;

tVar *a = op->offset + frame_stack.top->frame->local;
switch (op->offset)
{
case CONSTANT:
return op;
default:
{
if (likely(a->initialized))
return a;
else
abort();
}
}
}


GCC 7.4 -Og
eval(tVar*):
testrdi, rdi
je  .L4
mov rax, QWORD PTR frame_stack[rip]
mov rsi, QWORD PTR [rax]
mov edx, DWORD PTR [rdi+16]
movsx   rax, edx
lea rcx, [rax+rax*2]
lea rax, [0+rcx*8]
lea rax, [rsi+16+rax]
cmp edx, -1
je  .L5
cmp BYTE PTR [rax], 0
je  .L9
.L1:
rep ret
.L9:
sub rsp, 8
callabort
.L4:
mov eax, 0
ret
.L5:
mov rax, rdi
jmp .L1
frame_stack:
.zero   16

GCC 7.4 -O1
eval(tVar*):
testrdi, rdi
je  .L2
mov eax, DWORD PTR [rdi+16]
cmp eax, -1
je  .L2
mov rdx, QWORD PTR frame_stack[rip]
mov rdx, QWORD PTR [rdx]
cdqe
lea rax, [rax+rax*2]
lea rdi, [rdx+16+rax*8]
cmp BYTE PTR [rdi], 0
je  .L7
.L2:
mov rax, rdi
ret
.L7:
sub rsp, 8
callabort
frame_stack:
.zero   16


It seems -Og places the check 
cmp edx, -1
je  .L5

too late -> SEGFAULT


I have a segfault with GCC 7,8,9 on Intel Haswell. Looking at godbolt's output
for GCC 6.4, it is seems to be buggy too.

Godbolt: https://godbolt.org/z/m2yzDA

[Bug c++/91184] New: memory leak with enable_shared_from_this and pthread

[adl at gnu dot org]

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

Bug ID: 91184
   Summary: memory leak with enable_shared_from_this and pthread
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adl at gnu dot org
  Target Milestone: ---

Created attachment 46604
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46604=edit
preprocessed source

% gcc --version
gcc (Debian 20190706-1) 10.0.0 20190706 (experimental) [trunk revision 273162]

This is the gcc-snapshot package from Debian, running on amd64.   Since this
update, I have been observing memory leaks when enable_shared_from_this is used
with -pthread.


% cat foo.cc
#include 

struct foo: std::enable_shared_from_this
{
  ~foo() { }
};

int main()
{
  std::make_shared();
}
% g++ -W -Wall -g -o foo foo.cc -pthread
% valgrind -q --leak-check=yes ./foo
==27467== 32 bytes in 1 blocks are definitely lost in loss record 1 of 1
==27467==at 0x4835DEF: operator new(unsigned long)
(vg_replace_malloc.c:334)
==27467==by 0x401C59:
__gnu_cxx::new_allocator,
(__gnu_cxx::_Lock_policy)2> >::allocate(unsigned long, void const*)
(new_allocator.h:111)
==27467==by 0x401AB0:
std::allocator_traits, (__gnu_cxx::_Lock_policy)2> >
>::allocate(std::allocator, (__gnu_cxx::_Lock_policy)2> >&, unsigned long)
(alloc_traits.h:444)
==27467==by 0x40189B:
std::__allocated_ptr, (__gnu_cxx::_Lock_policy)2> > >
std::__allocate_guarded, (__gnu_cxx::_Lock_policy)2> >
>(std::allocator,
(__gnu_cxx::_Lock_policy)2> >&) (allocated_ptr.h:97)
==27467==by 0x40172C:
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count>(foo*&, std::_Sp_alloc_shared_tag >)
(shared_ptr_base.h:677)
==27467==by 0x401691: std::__shared_ptr::__shared_ptr>(std::_Sp_alloc_shared_tag
>) (shared_ptr_base.h:1368)
==27467==by 0x40162A:
std::shared_ptr::shared_ptr>(std::_Sp_alloc_shared_tag
>) (shared_ptr.h:408)
==27467==by 0x401425: std::shared_ptr std::allocate_shared>(std::allocator const&) (shared_ptr.h:844)
==27467==by 0x401344: std::shared_ptr std::make_shared()
(shared_ptr.h:860)
==27467==by 0x4011C2: main (foo.cc:10)
==27467== 

Removing the std::enable_shared_from_this inheritance, or the -pthread
option makes the leak disappear.

[Bug fortran/90903] Implement runtime checks for bit manipulation intrinsics

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Checks for the functions part committed.

Will now look into what can be done about the MVBITS subroutine.

[Bug fortran/90903] Implement runtime checks for bit manipulation intrinsics

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Tue Jul 16 19:58:15 2019
New Revision: 273535

URL: https://gcc.gnu.org/viewcvs?rev=273535=gcc=rev
Log:
2019-07-16  Harald Anlauf  

PR fortran/90903
* libgfortran.h: Add mask for -fcheck=bits option.
* options.c (gfc_handle_runtime_check_option): Add option "bits"
to run-time checks selectable via -fcheck.
* trans-intrinsic.c (gfc_conv_intrinsic_btest)
(gfc_conv_intrinsic_singlebitop, gfc_conv_intrinsic_ibits)
(gfc_conv_intrinsic_shift, gfc_conv_intrinsic_ishft)
(gfc_conv_intrinsic_ishftc): Implement run-time checks for the
POS, LEN, SHIFT, and SIZE arguments.
* gfortran.texi: Document run-time checks for bit manipulation
intrinsics.
* invoke.texi: Document new -fcheck=bits option.

PR fortran/90903
* gfortran.dg/check_bits_1.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/check_bits_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/libgfortran.h
trunk/gcc/fortran/options.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88918] [meta-bug] x86 intrinsic issues

[hjl.tools at gmail dot com]

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

Bug 90980 Summary: Missing AVX512 unaligned intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90980

   What|Removed |Added

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

[Bug target/90980] Missing AVX512 unaligned intrinsics

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 10.

[Bug target/91148] PowerPC build gets several warnings due to -Wformat-diag

[dje at gcc dot gnu.org]

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

--- Comment #12 from David Edelsohn  ---
Dumping work onto all other target maintainers at a time not of their choosing
isn't acceptable either.

[Bug tree-optimization/91183] strlen of a strcpy result with a conditional source not folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Blocks||83819

--- Comment #1 from Martin Sebor  ---
The root cause is the conditional guarding handle_char_store in
tree-ssa-strlen.c:

   else if (TREE_CODE (lhs) != SSA_NAME && !TREE_SIDE_EFFECTS (lhs))
{
  tree type = TREE_TYPE (lhs);
  if (TREE_CODE (type) == ARRAY_TYPE)
type = TREE_TYPE (type);
  if (TREE_CODE (type) == INTEGER_TYPE
  && TYPE_MODE (type) == TYPE_MODE (char_type_node)
  && TYPE_PRECISION (type) == TYPE_PRECISION (char_type_node))
{
  if (! handle_char_store (gsi))
return false;
}
}
}

which prevents the function from being called on the MEM_REF assignment:

  MEM  [(char * {ref-all})] = _4;

This case also came up in a recent discussion here:

  https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01790.html

As noted there, the function could be enhanced to handle these sorts of
expressions and the conditional relaxed.  Incidentally, some existing tests for
the strlen optimization already assume that this works.  They just happen to be
written in a way where this particular issue doesn't come up.  An example of
one such test is gcc.dg/strlenopt-19.c.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug tree-optimization/91183] New: strlen of a strcpy result with a conditional source not folded

[msebor at gcc dot gnu.org]

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

Bug ID: 91183
   Summary: strlen of a strcpy result with a conditional source
not folded
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing a solutuion for pr91147 I noticed that in the following GCC folds
the strlen call in f() into a constant but it doesn't know how to do that for
the second strlen call.

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout a.c
void f (int i)
{
  if (__builtin_strlen (i ? "123" : "456") != 3)   // folded to false
__builtin_abort ();
}

void g (int i)
{
  char a[4];
  __builtin_strcpy (a, i ? "123" : "456");   // transformed to MEM_REF
  if (3 != __builtin_strlen (a)) // not folded but could be
__builtin_abort ();
}

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

f (int i)
{
   [local count: 1073741824]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1911, cgraph_uid=2, symbol_order=1)

Removing basic block 3
g (int i)
{
  char a[4];
  long unsigned int _1;
  unsigned int _4;

   [local count: 1073741824]:
  if (i_3(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:

   [local count: 1073741824]:
  # _4 = PHI <3552564(2), 3355185(3)>
  MEM  [(char * {ref-all})] = _4;
  _1 = __builtin_strlen ();
  if (_1 != 3)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  return;

}

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #12 from Richard Earnshaw  ---
How do I invoke lto-wrapper inside gdb? it seems to pick up some magic options
via the environment...

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #11 from Richard Earnshaw  ---
Some pass in the compilation process must create that temporary file with the
options to gcc; but whichever pass this is doesn't appear in the output of "gcc
-v"

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #10 from Richard Earnshaw  ---
I'm not particularly familiar with how LTO is supposed to work.  I can
reproduce the crash on ARM as Martin described (but not on AArch64).  The
problem seems to be an assert that the number of files to analyse passed on the
command line matches the number of files described in the resolution file.  We
have:

lto1 -quiet -dumpbase  -mcpu=cortex-a72 -mfloat-abi=hard -mtls-dialect=gnu
-mcpu=cortex-a72 -mfloat-abi=hard -mtls-dialect=gnu -marm
-march=armv8-a+crc+simd -auxbase  -version -fno-openmp -fno-openacc
-fno-pie -fltrans-output-list=/tmp/ccoC6W9f.ltrans.out -fwpa
-fresolution=main.res -flinker-output=exec @/tmp/ccHCf4bh

Where ccHCf4bh contains:

main.o

and main.res contains:
1
main.o 1
195 4bf9aa6f81679e65 PREVAILING_DEF main

So if I've understood this correctly, the resolution file says to expect one
file to analyse, but two are passed.  It looks like something is interpreting
 as an additional file.

Going back another step, we see

/home/rearnsha/scratch/gnu/gcc-install/armv8l/gcc-9.1.0/libexec/gcc/armv8l-unkno
wn-linux-gnueabihf/9.1.0/lto-wrapper -fresolution=main.res -flinker-output=exec 
main.o 
/home/rearnsha/scratch/gnu/gcc-install/armv8l/gcc-9.1.0/bin/gcc @/tmp/cc8Su59l

where cc8Su59l contains:
-xlto
-c
-fno-openmp
-fno-openacc
-fno-pie
-mcpu=cortex-a72
-mfloat-abi=hard
-mtls-dialect=gnu
-marm
-march=armv8-a+crc+simd
-v

-save-temps
-mcpu=cortex-a72
-mfloat-abi=hard
-mtls-dialect=gnu
-marm
-march=armv8-a+crc+simd
-fltrans-output-list=/tmp/ccoC6W9f.ltrans.out
-fwpa
-fresolution=main.res
-flinker-output=exec
main.o

I think the problem is that '' mid-way through the list of options.  It
looks as though it has had a preceding -MF gobbled but not its argument.

Does this help any?

[Bug driver/90684] New alignment options incorrectly report error

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.2
  Known to fail||9.0

--- Comment #5 from Wilco  ---
Fixed on trunk and GCC9 branch.

[Bug driver/90684] New alignment options incorrectly report error

[wilco at gcc dot gnu.org]

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

--- Comment #4 from Wilco  ---
Author: wilco
Date: Tue Jul 16 16:17:39 2019
New Revision: 273533

URL: https://gcc.gnu.org/viewcvs?rev=273533=gcc=rev
Log:
Fix alignment option parser (PR90684)

Fix the alignment option parser to always allow up to 4 alignments.
Now -falign-functions=16:8:8:8 no longer reports an error.

gcc/
PR driver/90684
* gcc/opts.c (parse_and_check_align_values): Allow 4 alignment values.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/opts.c

[Bug target/89222] [7 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

   Target Milestone|8.5 |7.5

[Bug target/91148] PowerPC build gets several warnings due to -Wformat-diag

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Most of the issues were fixed before the warning was enabled: see r271338.  The
cleanup was done on x86 and it was expected that other targets would need some
minor changes before the warning could be enabled in -Werror.  As I mentioned
at the time I posted the original patch I hoped that target maintainers would
actively participate in the cleanup:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00739.html.  That's happening now
(thanks to you and others) so from my POV things are working well.  Since the
cleanup involves changes to tests expecting the author to do all the work
across all targets and validate the changes isn't realistic.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org,
   ||richard.earnshaw at arm dot com

--- Comment #9 from Martin Liška  ---
Similarly, the following fails:

$ abuild@needle:/tmp/XX> gcc main.c -flto -MMD -MF 

lto1: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2804
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib64/gcc/aarch64-suse-linux/9/../../../../aarch64-suse-linux/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Can please ARM guys step in a try to reproduce that?

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
It's not related to .d FE as it fails also with a different file name:

$ echo "int main() {}" > main.c && gcc -c -flto main.c && gcc -o a.out main.o
-flto -MMD -MF deps
gcc: error: deps: No such file or directory
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib64/gcc/aarch64-suse-linux/9/../../../../aarch64-suse-linux/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug rtl-optimization/91173] [9 Regression] ICE: in int_mode_for_mode, at stor-layout.c:403

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Tue Jul 16 14:57:51 2019
New Revision: 273531

URL: https://gcc.gnu.org/viewcvs?rev=273531=gcc=rev
Log:
PR rtl-optimization/91173
* g++.dg/pr91173.C: New test.

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

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Ok, we have a -dumpspecs option. If I use it for x86_64 and aarch64 I get a
small difference that should be fine:

--- x86_64.spec 2019-07-16 16:48:03.923522778 +0200
+++ aarch64.spec2019-07-16 16:47:03.380334911 +0200
@@ -1,8 +1,8 @@
 *asm:
-%{m16|m32:--32}  %{m16|m32|mx32:;:--64}  %{mx32:--x32} 
%{msse2avx:%{!mavx:-msse2avx}}
+%{mbig-endian:-EB} %{mlittle-endian:-EL} %{march=*:-march=%*}
%(asm_cpu_spec)%{mabi=*:-mabi=%*}

 *asm_debug:
-%{%:debug-level-gt(0):%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}}
%{fdebug-prefix-map=*:--debug-prefix-map %*}
+%{g*:%{%:debug-level-gt(0):--gdwarf2}}
%{fdebug-prefix-map=*:--debug-prefix-map %*}

 *asm_final:
 %{gsplit-dwarf: 
@@ -17,7 +17,7 @@
  as %(asm_options) %m.s %A }  }

 *cpp:
-%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
+%{pthread:-D_REENTRANT}

 *cpp_options:
 %(cpp_unique_options) %1 %{m*} %{std*} %{W**} %{w}
%{f*} %{g*:%{%:debug-level-gt(0):%{g*}
%{!fno-working-directory:-fworking-directory}}} %{O*} %{undef}
%{save-temps*:-fpch-preprocess}
@@ -32,7 +32,7 @@
 cc1 -E %{traditional|traditional-cpp:-traditional-cpp}

 *cc1:
-%{!mandroid|tno-android-cc:%(cc1_cpu) %{profile:-p};:%(cc1_cpu) %{profile:-p}
%{!mglibc:%{!muclibc:%{!mbionic: -mbionic}}}
%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC}
+%{profile:-p}%{%:sanitize(address):-funwind-tables}

 *cc1_options:
 %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}
%{!iplugindir*:%{fplugin*:%:find-plugindir()}} %1 %{!Q:-quiet}
%{!dumpbase:-dumpbase %B} %{d*} %{m*} %{aux-info*}
%{fcompare-debug-second:%:compare-debug-auxbase-opt(%b)} 
%{!fcompare-debug-second:%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase
%b}}}%{!c:%{!S:-auxbase %b}}  %{g*} %{O*} %{W**} %{w}
%{std*} %{v:-version} %{pg:-p} %{p} %{f*} %{undef}
%{Qn:-fno-ident} %{Qy:} %{-help:--help} %{-target-help:--target-help}
%{-version:--version} %{-help=*:--help=%*} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o
%b.s}}} %{fsyntax-only:-o %j} %{-param*} %{coverage:-fprofile-arcs
-ftest-coverage} %{fprofile-arcs|fprofile-generate*|coverage:  
%{!fprofile-update=single: %{pthread:-fprofile-update=prefer-atomic}}}
@@ -47,13 +47,13 @@

%{fstack-protector|fstack-protector-all|fstack-protector-strong|fstack-protector-explicit:}

 *endfile:
-%{!mandroid|tno-android-ld:%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}
   %{mpc32:crtprec32.o%s}%{mpc64:crtprec64.o%s}%{mpc80:crtprec80.o%s}
%{fvtable-verify=none:%s;  fvtable-verify=preinit:vtv_end_preinit.o%s; 
fvtable-verify=std:vtv_end.o%s}%{static:crtend.o%s; 
shared|static-pie|pie:crtendS.o%s;  :crtend.o%s} crtn.o%s
%{fopenacc|fopenmp:crtoffloadend%O%s};:%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}
   %{mpc32:crtprec32.o%s}%{mpc64:crtprec64.o%s}%{mpc80:crtprec80.o%s}
%{shared: crtend_so%O%s;: crtend_android%O%s}}
+%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}
%{fvtable-verify=none:%s;  fvtable-verify=preinit:vtv_end_preinit.o%s; 
fvtable-verify=std:vtv_end.o%s}%{static:crtend.o%s; 
shared|static-pie|pie:crtendS.o%s;  :crtend.o%s} crtn.o%s 

 *link:
-%{!r:--build-id} %{!static|static-pie:--eh-frame-hdr}
%{!mandroid|tno-android-ld:%{m16|m32|mx32:;:-m elf_x86_64}   
%{m16|m32:-m elf_i386}%{mx32:-m elf32_x86_64}  
%{shared:-shared}   %{!shared: %{!static:   %{!static-pie:
%{rdynamic:-export-dynamic} %{m16|m32:-dynamic-linker
%{muclibc:/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:%{mmusl:/lib/ld-musl-i386.so.1;:/lib/ld-linux.so.2
  %{m16|m32|mx32:;:-dynamic-linker
%{muclibc:/lib/ld64-uClibc.so.0;:%{mbionic:/system/bin/linker64;:%{mmusl:/lib/ld-musl-x86_64.so.1;:/lib64/ld-linux-x86-64.so.2
%{mx32:-dynamic-linker
%{muclibc:/lib/ldx32-uClibc.so.0;:%{mbionic:/system/bin/linkerx32;:%{mmusl:/lib/ld-musl-x32.so.1;:/libx32/ld-linux-x32.so.2}}
%{static:-static} %{static-pie:-static -pie --no-dynamic-linker -z
text}};:%{m16|m32|mx32:;:-m elf_x86_64}%{m16|m32:-m
elf_i386}%{mx32:-m elf32_x86_64}   %{shared:-shared}  
%{!shared: %{!static:   %{!static-pie:  
%{rdynamic:-export-dynamic} %{m16|m32:-dynamic-linker
%{muclibc:/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:%{mmusl:/lib/ld-musl-i386.so.1;:/lib/ld-linux.so.2
  %{m16|m32|mx32:;:-dynamic-linker
%{muclibc:/lib/ld64-uClibc.so.0;:%{mbionic:/system/bin/linker64;:%{mmusl:/lib/ld-musl-x86_64.so.1;:/lib64/ld-linux-x86-64.so.2
%{mx32:-dynamic-linker
%{muclibc:/lib/ldx32-uClibc.so.0;:%{mbionic:/system/bin/linkerx32;:%{mmusl:/lib/ld-musl-x32.so.1;:/libx32/ld-linux-x32.so.2}}
%{static:-static} %{static-pie:-static -pie --no-dynamic-linker -z text}}
%{shared: -Bsymbolic}}
+%{!r:--build-id} %{!static|static-pie:--eh-frame-hdr} %{h*}  
%{static:-Bstatic}  %{shared:-shared} 

[Bug rtl-optimization/91173] [9 Regression] ICE: in int_mode_for_mode, at stor-layout.c:403

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE: in   |[9 Regression] ICE: in
   |int_mode_for_mode, at   |int_mode_for_mode, at
   |stor-layout.c:403   |stor-layout.c:403

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk so far.  Will be backporting to at least some of the release
branches after soak time.

[Bug rtl-optimization/91173] [9/10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:403

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Tue Jul 16 14:44:44 2019
New Revision: 273529

URL: https://gcc.gnu.org/viewcvs?rev=273529=gcc=rev
Log:
PR rtl-optimization/91173
* tree-ssa-address.c (addr_for_mem_ref): If the base is an
SSA_NAME with a constant value, fold its value into the offset
and clear the base before calling gen_addr_rtx.

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

[Bug c++/91182] New: deprecated attribute string-literal

[aaron.ballman+gcc at gmail dot com]

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

Bug ID: 91182
   Summary: deprecated attribute string-literal
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron.ballman+gcc at gmail dot com
  Target Milestone: ---

Using a wide string literal argument to the deprecated attribute has
unfortunate behavior when trying to print that argument as part of a
diagnostic. Consider:
```
[[deprecated(L"Test")]] void foo();

int main() {
  foo();
}
```
Produces this for output:

warning: 'void foo()' is deprecated: T [-Wdeprecated-declarations]

It seems that the diagnostic is treating the literal as always being a narrow
string literal. Similar bad behavior happens with u and U prefixes as well.

[Bug tree-optimization/91181] [10 Regression] Failing as_as type conversion in vect_build_slp_tree_1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||alejandro at gcc dot gnu.org
  Known to fail||10.0

--- Comment #2 from Martin Liška  ---
Started with r271704.

Test-case without warnings:

$ cat pr91181.c
enum { a, b, c };
float *d, *e;
int f, g, h, i;

void j() {
  float a;
  for (; h; h++) {
i = h * 4;
a = d[i + b];
if (a) {
  e[i + b] = g < d[i + b] * f * a ? g : d[i + b] * f * a;
  e[i + c] = g < d[i + c] * f * a ? g : d[i + c] * f * a;
}
e[i + b] = e[i + c];
  }
}

[Bug tree-optimization/91180] [10 Regression] wrong code at -O and above with __builtin_memset()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-16
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine (partial def support).

[Bug tree-optimization/91181] [10 Regression] Failing as_as type conversion in vect_build_slp_tree_1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Known to work||9.1.1
   Keywords||needs-bisection
   Last reconfirmed||2019-07-16
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|Failing as_as type  |[10 Regression] Failing
   |conversion in   |as_as type conversion in
   |vect_build_slp_tree_1   |vect_build_slp_tree_1
   Target Milestone|--- |10.0

--- Comment #1 from Richard Biener  ---
I will have a look.

We have

860   if (rhs_code == CALL_EXPR)
861 {
862   if (!compatible_calls_p (as_a  (stmts[0]->stmt),
863as_a  (stmt)))
864 {

and

(gdb) p debug_gimple_stmt (stmts[0]->stmt)
# VUSE <.MEM_44>
a_36 = *_6;
$2 = void
(gdb) p debug_gimple_stmt (stmt)
# VUSE <.MEM_37>
_19 = .MASK_LOAD (_18, 32B, _47);
$3 = void

so likely caused by the SLP support for masked loads patch.

[Bug target/89222] [7 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #12 from Wilco  ---
Fixed on all active branches

[Bug target/89222] [7 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[wilco at gcc dot gnu.org]

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

--- Comment #11 from Wilco  ---
Author: wilco
Date: Tue Jul 16 13:13:26 2019
New Revision: 273527

URL: https://gcc.gnu.org/viewcvs?rev=273527=gcc=rev
Log:
[ARM] Fix PR89222

The GCC optimizer can generate symbols with non-zero offset from simple
if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations
with offsets fail if it changes bit zero and the relocation forces bit zero
to true.  The fix is to disable offsets on function pointer symbols.  

gcc/
PR target/89222
* config/arm/arm.md (movsi): Use targetm.cannot_force_const_mem
to decide when to split off a non-zero offset from a symbol.
* config/arm/arm.c (arm_cannot_force_const_mem): Disallow offsets
in function symbols.

testsuite/
PR target/89222
* gcc.target/arm/pr89222.c: Add new test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/pr89222.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/arm/arm.c
branches/gcc-7-branch/gcc/config/arm/arm.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/89222] [7/8 regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os

[wilco at gcc dot gnu.org]

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

--- Comment #10 from Wilco  ---
Author: wilco
Date: Tue Jul 16 12:37:14 2019
New Revision: 273526

URL: https://gcc.gnu.org/viewcvs?rev=273526=gcc=rev
Log:
[ARM] Fix PR89222

The GCC optimizer can generate symbols with non-zero offset from simple
if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations
with offsets fail if it changes bit zero and the relocation forces bit zero
to true.  The fix is to disable offsets on function pointer symbols.  

gcc/
PR target/89222
* config/arm/arm.md (movsi): Use targetm.cannot_force_const_mem
to decide when to split off a non-zero offset from a symbol.
* config/arm/arm.c (arm_cannot_force_const_mem): Disallow offsets
in function symbols.

testsuite/
PR target/89222
* gcc.target/arm/pr89222.c: Add new test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/arm/pr89222.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/arm/arm.c
branches/gcc-8-branch/gcc/config/arm/arm.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/89190] [ARM] armv8-m.base invalid ldm ICE

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[8 regression][ARM] |[ARM] armv8-m.base invalid
   |armv8-m.base invalid ldm|ldm ICE
   |ICE |

--- Comment #8 from Wilco  ---
.

[Bug target/89190] [8 regression][ARM] armv8-m.base invalid ldm ICE

[wilco at gcc dot gnu.org]

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

--- Comment #7 from Wilco  ---
Backported to GCC8 branch, and added missing testcase to trunk and GCC9. All
fixed.

[Bug target/89190] [8 regression][ARM] armv8-m.base invalid ldm ICE

[wilco at gcc dot gnu.org]

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

--- Comment #6 from Wilco  ---
Author: wilco
Date: Tue Jul 16 12:12:01 2019
New Revision: 273525

URL: https://gcc.gnu.org/viewcvs?rev=273525=gcc=rev
Log:
Add missing testcase for PR89190

testsuite/
PR target/89190
* gcc.target/arm/pr89190.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/arm/pr89190.c
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug target/89190] [8 regression][ARM] armv8-m.base invalid ldm ICE

[wilco at gcc dot gnu.org]

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

--- Comment #5 from Wilco  ---
Author: wilco
Date: Tue Jul 16 12:06:55 2019
New Revision: 273524

URL: https://gcc.gnu.org/viewcvs?rev=273524=gcc=rev
Log:
Add missing testcase for PR89190

testsuite/
PR target/89190
* gcc.target/arm/pr89190.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr89190.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/89190] [8 regression][ARM] armv8-m.base invalid ldm ICE

[wilco at gcc dot gnu.org]

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

--- Comment #4 from Wilco  ---
Author: wilco
Date: Tue Jul 16 12:00:42 2019
New Revision: 273523

URL: https://gcc.gnu.org/viewcvs?rev=273523=gcc=rev
Log:
[ARM] Fix Thumb-1 ldm (PR89190)

This patch fixes an ICE in the Thumb-1 LDM peepholer.  Thumb-1 LDMs
always update the base register except if the base is loaded.
The current implementation rejects LDMs where the base is not dead,
however this doesn't exclude the case where the base is loaded as
well as dead.  Fix this by explicitly checking whether the base is
loaded.  Also enable LDMs which load the first register.

gcc/
PR target/89190
* config/arm/arm.c (ldm_stm_operation_p) Set
addr_reg_in_reglist correctly for first register.
(load_multiple_sequence): Remove dead base check.
(gen_ldm_seq): Correctly set write_back for Thumb-1.

testsuite/
PR target/89190
* gcc.target/arm/pr89190.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/arm/pr89190.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/arm/arm.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/91157] [10 Regression] ICE: verify_gimple failed (error: position plus size exceeds size of referenced object in 'bit_field_ref')

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 46603
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46603=edit
gcc10-pr91157.patch

Untested fix.

[Bug rtl-optimization/91164] [10 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 114 should be 112, not 16)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/91164] [10 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 114 should be 112, not 16)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jul 16 11:37:05 2019
New Revision: 273522

URL: https://gcc.gnu.org/viewcvs?rev=273522=gcc=rev
Log:
PR rtl-optimization/91164
* dse.c (rest_of_handle_dse): If dead edges have been purged,
invalidate dominance info.

* g++.dg/opt/pr91164.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr91164.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dse.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91181] New: Failing as_as type conversion in vect_build_slp_tree_1

[jamborm at gcc dot gnu.org]

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

Bug ID: 91181
   Summary: Failing as_as type conversion in vect_build_slp_tree_1
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

When compiling C snippet:

enum { a, b, c };
float *d, *e;
f, g, h, i;
j() {
  float a;
  for (; h; h++) {
i = h * 4;
a = d[i + b];
if (a) {
  e[i + b] = g < d[i + b] * f * a ? g : d[i + b] * f * a;
  e[i + c] = g < d[i + c] * f * a ? g : d[i + c] * f * a;
}
e[i + b] = e[i + c];
  }
}

with -Ofast -march=sandybridge test.c (march can be also znver1, for
example) and trunk revision 273492, I get:

$ ~/gcc/trunk/inst/bin/gcc -Ofast -w -march=sandybridge test.c
during GIMPLE pass: vect
test.c: In function ‘j’:
test.c:4:1: internal compiler error: in as_a, at is-a.h:197
4 | j() {
  | ^
0x110afb6 gcall* as_a(gimple*)
/home/mjambor/gcc/trunk/src/gcc/is-a.h:197
0x110afb6 vect_build_slp_tree_1
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:862
0x110d96c vect_build_slp_tree_2
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1161
0x110d4e8 vect_build_slp_tree
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1073
0x110dc47 vect_build_slp_tree_2
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1219
0x110d4e8 vect_build_slp_tree
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1073
0x110dc47 vect_build_slp_tree_2
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1219
0x110d4e8 vect_build_slp_tree
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1073
0x110dc47 vect_build_slp_tree_2
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1219
0x110d4e8 vect_build_slp_tree
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1073
0x110dc47 vect_build_slp_tree_2
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1219
0x110d4e8 vect_build_slp_tree
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1073
0x110dc47 vect_build_slp_tree_2
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1219
0x110d4e8 vect_build_slp_tree
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1073
0xfd7 vect_analyze_slp_instance
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:1986
0x1112dc8 vect_analyze_slp(vec_info*, unsigned int)
/home/mjambor/gcc/trunk/src/gcc/tree-vect-slp.c:2187
0x10f7b44 vect_analyze_loop_2
/home/mjambor/gcc/trunk/src/gcc/tree-vect-loop.c:1985
0x10f8ff7 vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
/home/mjambor/gcc/trunk/src/gcc/tree-vect-loop.c:2379
0x111a12a try_vectorize_loop_1
/home/mjambor/gcc/trunk/src/gcc/tree-vectorizer.c:887
0x111a71b try_vectorize_loop
/home/mjambor/gcc/trunk/src/gcc/tree-vectorizer.c:1033

The testcase was creduced from 526.blender_r from SPEC 2017.

[Bug tree-optimization/83518] [8/9 Regression] Missing optimization: useless instructions should be dropped

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #16 from Wilco  ---
Reopen since it still fails on AArch64.

[Bug testsuite/91175] [9 regression] g++.old-deja/g++.pt/instantiate4.C fails starting with r273489

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug tree-optimization/91180] New: [10 Regression] wrong code at -O and above with __builtin_memset()

[zsojka at seznam dot cz]

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

Bug ID: 91180
   Summary: [10 Regression] wrong code at -O and above with
__builtin_memset()
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 46602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46602=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-273505-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-273505-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20190716 (experimental) (GCC) 

This seems to be a quite recent regression affecting various targets.

[Bug libstdc++/91170] [9/10 Regression] Crash in pdns resolver

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Jonathan Wakely from comment #2)
> That mostly just adds static_assert checks, which can't change anything at
> runtime.

It changes how we get to keys/values besides moving static asserts but I
know nothing about this code so cannot assess whether the change does
anything.  At least it's the only change in the revision range that looks
remotely related to the backtrace (maybe the tuples change as well).

But I haven't yet tried to reproduce either.

[Bug testsuite/91175] [9 regression] g++.old-deja/g++.pt/instantiate4.C fails starting with r273489

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Tue Jul 16 10:21:57 2019
New Revision: 273521

URL: https://gcc.gnu.org/viewcvs?rev=273521=gcc=rev
Log:
Do not use -Werror in a test that has -frepo warning (PR testsuite/91175).

2019-07-16  Martin Liska  

PR testsuite/91175
* g++.old-deja/g++.pt/instantiate4.C: Do not use -Werror.

Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/g++.old-deja/g++.pt/instantiate4.C

[Bug testsuite/91175] [9 regression] g++.old-deja/g++.pt/instantiate4.C fails starting with r273489

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Andreas Schwab from comment #5)
> Why does it clash only on arm and aarch64?

I'll debug that, it's really strange.

[Bug target/91174] Suboptimal code for arithmetic with bool and char

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #5 from Florian Weimer  ---
Closing.

[Bug tree-optimization/91178] [9/10 Regression] Infinite recursion in split_constant_offset in slp after r260289

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The main issue is that loop vectorization creates a chain of increments

  # vectp_f.21_116 = PHI 
  vect__16.23_118 = MEM  [(int *)vectp_f.21_116];
  vectp_f.21_119 = vectp_f.21_116 + 16;
  vectp_f.21_121 = vectp_f.21_119 + 16;
  vectp_f.21_123 = vectp_f.21_121 + 16;
  vectp_f.21_125 = vectp_f.21_123 + 16;
...
  vectp_f.21_182363 = vectp_f.21_182361 + 16;
  vectp_f.21_182365 = vectp_f.21_182363 + 16;
  vectp_f.21_182367 = vectp_f.21_182365 + 16;
  vect__16.91149_182369 = VEC_PERM_EXPR ;
  vect__16.91150_182370 = VEC_PERM_EXPR ;
  vect__16.91151_182371 = VEC_PERM_EXPR ;
  vect__16.91152_182372 = VEC_PERM_EXPR ;
  vect__16.91153_182373 = VEC_PERM_EXPR ;
  vect__16.91154_182374 = VEC_PERM_EXPR ;
  vect__16.91155_182375 = VEC_PERM_EXPR ;
  vect__16.91156_182376 = VEC_PERM_EXPR ;
  vect__16.91157_182377 = VEC_PERM_EXPR ;
  vect__73.91158_182378 = vect__73.20_106 - vect__16.91149_182369;
  vect__73.91158_182379 = vect__73.20_107 - vect__16.91150_182370;
  vect__73.91158_182380 = vect__73.20_108 - vect__16.91151_182371;
  vect__73.91158_182381 = vect__73.20_109 - vect__16.91152_182372;
  vect__73.91158_182382 = vect__73.20_110 - vect__16.91153_182373;
  vect__73.91158_182383 = vect__73.20_111 - vect__16.91154_182374;
  vect__73.91158_182384 = vect__73.20_112 - vect__16.91155_182375;
  vect__73.91158_182385 = vect__73.20_113 - vect__16.91156_182376;
  vect__73.91158_182386 = vect__73.20_114 - vect__16.91157_182377;
  vectp_f.21_117 = vectp_f.21_182367 + 16;
  ivtmp_182463 = ivtmp_182462 + 1;
  if (ivtmp_182463 < bnd.17_102)
goto ; [0.00%]
  else
goto ; [100.00%]

where it first generates one load for each of the increments and then
the permutation makes most of them dead.  For interleaving we have some
cut-off to avoid this kind of code-gen but for SLP we don't.
DR group size is 91126 here and gap 91125 (aka single element interleaving).

[Bug target/91174] Suboptimal code for arithmetic with bool and char

[antoshkka at gmail dot com]

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

--- Comment #4 from Antony Polukhin  ---
Sorry, now I understood that the bug is invalid. Please close.

[Bug target/91174] Suboptimal code for arithmetic with bool and char

[fw at gcc dot gnu.org]

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

--- Comment #3 from Florian Weimer  ---
(In reply to Antony Polukhin from comment #2)
> (In reply to Florian Weimer from comment #1)
> > For which ABI do you propose the change?  It's not correct for GNU/Linux:
> 
> As far as I understand the proposed change does not touch ABI. `lea eax,
> [rdi + 48]` is equivalent to `movzx+add`

According to the x86-64 psABI, for bool, only the lower 8 bits of the register
are defined when passing a bool value.  This means that the movzx instruction
is not optional because the int result needs all 32 bits defined.

GCC already uses lea in cases where the upper 24 bits do not matter, as in this
example:

char test (bool x) {
return '0' + x;
}

[Bug target/91174] Suboptimal code for arithmetic with bool and char

[antoshkka at gmail dot com]

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

--- Comment #2 from Antony Polukhin  ---
(In reply to Florian Weimer from comment #1)
> For which ABI do you propose the change?  It's not correct for GNU/Linux:

As far as I understand the proposed change does not touch ABI. `lea eax, [rdi +
48]` is equivalent to `movzx+add`

[Bug lto/91163] ARM lto optimalization fail in big-endian case (error: could not unlink output file)

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

--- Comment #10 from Richard Earnshaw  ---
Changing to invalid, as not a bug in gcc.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|aarch64-linux-gnu   |aarch64-*-* arm*-*-*
   Host|aarch64-linux-gnu   |
  Build|aarch64-linux-gnu   |

--- Comment #5 from Andreas Schwab  ---
Why does it clash only on arm and aarch64?

[Bug rtl-optimization/91173] [9/10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:403

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug testsuite/91175] [9 regression] g++.old-deja/g++.pt/instantiate4.C fails starting with r273489

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-16
  Known to work||9.1.0
   Target Milestone|--- |9.2
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug bootstrap/91176] [10 regression] AArch64 bootstrap fails since r273479

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/91178] [9/10 Regression] Infinite recursion in split_constant_offset in slp after r260289

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.2

--- Comment #2 from Richard Biener  ---
I will have a look.  The function is prone to exponential behavior.

[Bug bootstrap/91176] [10 regression] AArch64 bootstrap fails since r273479

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #11 from rsandifo at gcc dot gnu.org  
---
Patch applied -- thanks for fix & preapproval.

[Bug go/91172] Command line option for a wrong language is not reported with -Werror=warning_name syntax

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-16
   Assignee|ian at airs dot com|marxin at gcc dot 
gnu.org
Summary|go1: error: control reaches |Command line option for a
   |end of non-void function in |wrong language is not
   |libgo/go/cmd/cgo/gcc.go |reported with
   ||-Werror=warning_name syntax
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #3 from Martin Liška  ---
I've got:

$ gcc -Wtarget-lifetime /tmp/main.c
cc1: warning: command line option ‘-Wtarget-lifetime’ is valid for Fortran but
not for C

$ gcc -Wtarget-lifetime /tmp/main.c --help=warning -Q  | grep target-lifetime
cc1: warning: command line option ‘-Wtarget-lifetime’ is valid for Fortran but
not for C
  -Wtarget-lifetime [disabled]

But:

$ gcc -Werror=target-lifetime /tmp/main.c
$ gcc -Werror=target-lifetime /tmp/main.c --help=warning -Q  | grep target
  -Wtarget-lifetime [enabled]

Lemme take it.

[Bug bootstrap/91176] [10 regression] AArch64 bootstrap fails since r273479

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Jul 16 08:12:05 2019
New Revision: 273507

URL: https://gcc.gnu.org/viewcvs?rev=273507=gcc=rev
Log:
PR91176: Skip debug insns when computing inline costs

Apply Honza's fix for an aarch64-linux-gnu bootstrap failure.

2019-07-16  Jan Hubicka  

gcc/
PR bootstrap/91176
* ipa-fnsummary.c (analyze_function_body): Skip debug stmts

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-fnsummary.c

[Bug tree-optimization/91178] [9/10 Regression] Infinite recursion in split_constant_offset in slp after r260289

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-16
 CC||belyshev at depni dot 
sinp.msu.ru
Summary|GCC fails with internal |[9/10 Regression] Infinite
   |compiler error. |recursion in
   ||split_constant_offset in
   ||slp after r260289
 Ever confirmed|0   |1

--- Comment #1 from Serge Belyshev  ---
git bisect points at r260289, which is "[PATCH] Merge SLP and non-SLP
vectorization costing":
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00599.html

stack trace shows infinite recursion in split_constant_offset():

(gdb) run -quiet -O3 ~/src/bugs/bug91178.c
...
Program received signal SIGSEGV, Segmentation fault.
...
(gdb) bt -100
...
#190637 0x017333b6 in split_constant_offset (exp=, var=var@entry=0x7fffe028, off=off@entry=0x7fffe018,
cache=...) at ../../gcc/gcc/tree-data-ref.c:815
#190638 0x0173251f in split_constant_offset_1
(type=type@entry=, op0=,
code=code@entry=POINTER_PLUS_EXPR, op1=,
var=var@entry=0x7fffe278, off=off@entry=0x7fffe270, cache=...) at
../../gcc/gcc/tree-data-ref.c:618
#190639 0x01732c6f in split_constant_offset_1
(type=type@entry=, op0=,
code=, op1=, var=var@entry=0x7fffe278,
off=off@entry=0x7fffe270, cache=...) at ../../gcc/gcc/tree-data-ref.c:725
#190640 0x017333b6 in split_constant_offset (exp=exp@entry=, var=var@entry=0x7fffe3b0, off=off@entry=0x7fffe388,
cache=...) at ../../gcc/gcc/tree-data-ref.c:815
#190641 0x01733441 in split_constant_offset (exp=, var=var@entry=0x7fffe3b0, off=off@entry=0x7fffe388) at
../../gcc/gcc/tree-data-ref.c:828
#190642 0x01733a1c in dr_analyze_innermost (drb=drb@entry=0x353ad10,
ref=ref@entry=, loop=loop@entry=0x0,
stmt=stmt@entry=0x73cd3960) at ../../gcc/gcc/tree-data-ref.c:967
#190643 0x0173517f in create_data_ref (nest=,
loop=loop@entry=0x776d1000, memref=memref@entry=,
stmt=stmt@entry=, is_read=is_read@entry=true,
is_conditional_in_stmt=is_conditional_in_stmt@entry=false) at
../../gcc/gcc/tree-data-ref.c:1239
#190644 0x01735598 in find_data_references_in_stmt
(nest=nest@entry=0x0, stmt=stmt@entry=,
datarefs=datarefs@entry=Python Exception  There is no member
or method named m_vecpfx.: 
0x7fffe5a0) at ../../gcc/gcc/tree-ssa-loop.h:80
#190645 0x0174de04 in vect_find_stmt_data_reference
(loop=loop@entry=0x0, stmt=stmt@entry=,
datarefs=datarefs@entry=Python Exception  There is no member
or method named m_vecpfx.: 
0x7fffe658) at ../../gcc/gcc/tree-vect-data-refs.c:4027
#190646 0x00f582ac in vect_slp_bb (bb=bb@entry=) at ../../gcc/gcc/tree-vect-slp.c:3036
#190647 0x00f5b866 in (anonymous
namespace)::pass_slp_vectorize::execute (this=,
fun=0x776ca000) at ../../gcc/gcc/tree-vectorizer.c:1310
#190648 0x00b615fe in execute_one_pass (pass=pass@entry=) at ../../gcc/gcc/passes.c:2474
...

[Bug c++/91179] New: Spurious -Wconversion warning after promotion

[gennaro.prota+gccbugzilla at gmail dot com]

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

Bug ID: 91179
   Summary: Spurious -Wconversion warning after promotion
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

Hi,

this a reduced test case for:

 
.

It is similar to bug 88566.

  struct X
  {
  X() : m() {}
  unsigned char   m[ 10 ] ;
  } ;

  int
  main()
  {
  X x ;
  unsigned char const a = x.m[ 0 ] >> 3 ;
  }

Command line:
g++ -Wconversion spurious_wconversion.cpp

Compiler output:

spurious_wconversion.cpp: In function ‘int main()’:
spurious_wconversion.cpp:11:38: warning: conversion to ‘unsigned char’ from
‘int’ may alter its value [-Wconversion]
 unsigned char const a = x.m[ 0 ] >> 3 ;

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 7.4.0 (GCC)

[Bug lto/91163] ARM lto optimalization fail in big-endian case (error: could not unlink output file)

[jdobry at centrum dot cz]

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

jdobry at centrum dot cz changed:

   What|Removed |Added

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

--- Comment #9 from jdobry at centrum dot cz ---
Problem is in binutils 2.31 & 2.32.
Fix is in GIT repository already.
Mark as resolved. It don't need changes in LTO componnent.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Ok, so I can confirm it's related to D front-end, where the following patch can
paper over that:

diff --git a/gcc/d/lang-specs.h b/gcc/d/lang-specs.h
index 098f0f98b29..d3f41d23c5a 100644
--- a/gcc/d/lang-specs.h
+++ b/gcc/d/lang-specs.h
@@ -23,7 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 {".di", "@d", 0, 1, 0 },
 {"@d",
   "%{!E:d21 %i %(cc1_options) %I %{nostdinc*} %{i*} %{I*} %{J*} \
-%{H} %{Hd*} %{Hf*} %{MD:-MD %b.deps} %{MMD:-MMD %b.deps} \
+%{H} %{Hd*} %{Hf*} \
 %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} \
 %{X:-Xf %b.json} %{Xf*} \
 %{v} %{!fsyntax-only:%(invoke_as)}}", 0, 1, 0 },

So the general issue is that .d files are clasing between D source files and
dependecy files.

Would it be possible for the future to start using the .deps extension,
similarly what D language does?