[Bug libstdc++/83709] Inserting duplicates into an unordered associative containers causes the container to invalidate iterators

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

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

--- Comment #3 from François Dumont  ---
Should be fixed now, thanks again for reporting.

[Bug tree-optimization/83784] New: Missed optimization with bitfield

[daniel.santos at pobox dot com]

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

Bug ID: 83784
   Summary: Missed optimization with bitfield
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.santos at pobox dot com
  Target Milestone: ---

Created attachment 43095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43095=edit
test case

The layout of bitfields in memory is, of course, undefined in the C standard
and is implementation-dependent.  But when I happen to guess how gcc will lay
it out correctly, I would like for these pack and unpack functions to
compile-out.  I'm only doing this because I happen to need to be able to know
what 32-bit portion of a 64-bit value has one of the fields (for futex
operations) and bitfields are syntactically easier to work with.  But due to
this flaw, I have to go back to shifting, ANDing, ORing, etc.

The attached test case is probably not as simple as it could be as I'm testing
both 32 and 64-bit code on x86, but the below is probably a descent summary
(for 64-bits):

union u
{
unsigned long ulong_val;
struct {
unsigned long a:4;
unsigned long b:60;
};
};

union u pack(union u in)
{
union u ret;
ret.ulong_val  |= in.b;
ret.ulong_val <<= 4;
ret.ulong_val  |= in.a;
return ret;
}

The above pack function compiles into the no-op I would expect:
pack:
.LFB12:
.cfi_startproc
movq%rdi, %rax
ret
.cfi_endproc


But if I use three bitfields, my pack function is no longer a no-op:

union u
{
unsigned long ulong_val;
struct {
unsigned long a:4;
unsigned long b:30;
unsigned long c:30;
};
};

union u pack( union u in )
{
union u ret;
ret.ulong_val   = in.c;
ret.ulong_val <<= 30;
ret.ulong_val  |= in.b;
ret.ulong_val <<= 4;
ret.ulong_val  |= in.a;
return ret;
}

And here's the output (with hex immediates for ANDs)
pack:
pack:
.LFB11:
.cfi_startproc
movq%rdi, %rax
movq%rdi, %rdx
andl$0xf, %edi
shrq$34, %rax
shrq$4, %rdx
salq$30, %rax
andl$0x3fff, %edx
orq %rdx, %rax
salq$4, %rax
orq %rdi, %rax
ret
.cfi_endproc


Possibly related to bug #15596 and maybe even a duplicate of bug #35363, but
I'm uncertain.  I have only tested on gcc 5.4.0 and 8 from git so far and only
x86, but I'm going to *guess* this is a tree-optimization issue and not the x86
backend.

[Bug tree-optimization/83781] [8 Regression] Bootstrap failed on x86 with --with-arch=corei7 --with-cpu=corei7

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|target  |tree-optimization
 Resolution|--- |FIXED

--- Comment #9 from Martin Sebor  ---
r256477 should fix the bootstrap failure.   Please open a new bug for any new
issues with the same commit.

[Bug target/83781] [8 Regression] Bootstrap failed on x86 with --with-arch=corei7 --with-cpu=corei7

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Thu Jan 11 05:13:57 2018
New Revision: 256477

URL: https://gcc.gnu.org/viewcvs?rev=256477=gcc=rev
Log:
PR tree-optimization/83781 - Bootstrap failed on x86 with --with-arch=corei7
  --with-cpu=corei7

gcc/ChangeLog:
* gimple-fold.c (get_range_strlen): Avoid treating arrays of pointers
as string arrays.

gcc/testsuite/ChangeLog:
* gcc.dg/strlenopt-42.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/strlenopt-42.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64

[matthew at wil dot cx]

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

--- Comment #5 from Matthew Wilcox  ---
Hi Aldy!

Thanks for looking into this.  Yes, I agree, there's no way that GCC can know
this is a constant, but that *should* have been taken care of.  Please pardon
me copying and pasting from the original source file rather than the
preprocessed source, but I find it utterly impossible to work with the
preprocessed source ...

#define atomic_sub_return(i,v)  \
({  \
int __ia64_asr_i = (i); \
(__builtin_constant_p(i)\
 && (   (__ia64_asr_i ==   1) || (__ia64_asr_i ==   4)  \
 || (__ia64_asr_i ==   8) || (__ia64_asr_i ==  16)  \
 || (__ia64_asr_i ==  -1) || (__ia64_asr_i ==  -4)  \
 || (__ia64_asr_i ==  -8) || (__ia64_asr_i == -16)))\
? ia64_fetch_and_add(-__ia64_asr_i, &(v)->counter)  \
: ia64_atomic_sub(__ia64_asr_i, v); \
})

That __builtin_constant_p() *should* have led GCC to throw up its hands, not
bother checking for the +/- 1, 4, 8, 16 cases and just call ia64_atomic_sub(). 
Looking at the disassembly, I see a BBB bundle, indicating quite strongly to me
that it is testing for all of these cases, and the __builtin_constant_p is
being ... ignored?  misunderstood?

Thanks!

[Bug tree-optimization/81703] memcpy folding defeats strlen optimization

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Fixed.

[Bug tree-optimization/81703] memcpy folding defeats strlen optimization

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Thu Jan 11 04:37:48 2018
New Revision: 256475

URL: https://gcc.gnu.org/viewcvs?rev=256475=gcc=rev
Log:
2018-01-11  Martin Sebor  
Prathamesh Kulkarni  

PR tree-optimization/83501
PR tree-optimization/81703

* tree-ssa-strlen.c (get_string_cst): Rename...
(get_string_len): ...to this.  Handle global constants.
(handle_char_store): Adjust.

testsuite/
* gcc.dg/strlenopt-39.c: New test-case.
* gcc.dg/pr81703.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr81703.c
trunk/gcc/testsuite/gcc.dg/strlenopt-39.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/83501] [8 Regression] strlen(a) not folded after strcpy(a, "...")

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #8 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Thu Jan 11 04:37:48 2018
New Revision: 256475

URL: https://gcc.gnu.org/viewcvs?rev=256475=gcc=rev
Log:
2018-01-11  Martin Sebor  
Prathamesh Kulkarni  

PR tree-optimization/83501
PR tree-optimization/81703

* tree-ssa-strlen.c (get_string_cst): Rename...
(get_string_len): ...to this.  Handle global constants.
(handle_char_store): Adjust.

testsuite/
* gcc.dg/strlenopt-39.c: New test-case.
* gcc.dg/pr81703.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr81703.c
trunk/gcc/testsuite/gcc.dg/strlenopt-39.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug target/83768] ARM: wrong optimization

[sorganov at gmail dot com]

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

--- Comment #2 from Sergey Organov  ---
4.8.3 doesn't have the issue, and I don't have fast access to any 4.9. 

So presumably it has been fixed between 5.4.0 and 5.4.1... It'd still be nice
to know if there is some optimization switch in 5.4.0 to be turned off to
overcome the problem. Any idea?

[Bug target/83781] [8 Regression] Bootstrap failed on x86 with --with-arch=corei7 --with-cpu=corei7

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Created attachment 43094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43094=edit
Preliminary patch.

I'm testing the attached patch.

[Bug target/83781] [8 Regression] Bootstrap failed on x86 with --with-arch=corei7 --with-cpu=corei7

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
I can reproduce the problem with the following test case.  Let me take care of
it.

$ cat z.c && gcc -O2 -S -Wall z.c
const char* const a[32] = { "1", "12", "123" };

char d[4];

void f (int i)
{
  __builtin_sprintf (d, "%s", a[i]);
}
z.c: In function ‘f’:
z.c:7:26: warning: ‘%s’ directive writing up to 255 bytes into a region of size
4 [-Wformat-overflow=]
   __builtin_sprintf (d, "%s", a[i]);
  ^~

[Bug target/83781] [8 Regression] Bootstrap failed on x86 with --with-arch=corei7 --with-cpu=corei7

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
On i686, it failed with

--prefix=/usr/8.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-libmpx i686-linux --with-fpmath=sse

[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-11
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Aldy Hernandez  ---
I can reproduce this on mainline, however the testcase is suspect.

I see that page_ref_sub() is defined as:

int __ia64_asr_i = ((nr))
...
if (__ia64_asr_i == xxx)
else if (__ia64_asr_i == yyy)
else if (__ia64_asr_i == yyy)
etc
else _tmp = __bad_increment_for_ia64_fetch_and_add();

The thing I see is that NR doesn't seem like an inlineable constant when passed
from the caller:

nr = 1UL << compound_order(page)
...
page_ref_sub(page, nr)

because:

unsigned int compound_order(struct page *page)
{
 if (!PageHead(page))
  return 0;
 return page[1].compound_order;
}

And sure enough...after early inlining, both compound_order and page_ref_sub
are inlined into shmem_add_to_page_cache and we can see:

  _117 = MEM[(struct page *)page_49(D) + 56B].D.16951.D.16950.compound_order;

There's no way the compiler can know that _117 is a known constant if it's
reading the value from memory.

OTOH, the other *_bad* thinggies do get inlined correctly because they depend
on sizeof(stuff), whose size can be determined at compile time.

Matthew, could you double check here?  Maybe I missed something, but perhaps a
reduced testcase would help analyze better (at least for me :)).

[Bug target/83781] [8 Regression] Bootstrap failed on x86 with --with-arch=corei7 --with-cpu=corei7

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The gcc/hsa-dump.c warning doesn't seem to correspond to the latest sources. 
hsa_seg_name() returns one of a number of short strings, the longest being
"UNKNOWN_SEGMENT" but the warning says the %s argument can be up to 71
characters long.

[Bug target/83781] [8 Regression] Bootstrap failed on x86

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-11
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
Please configure GCC with

--with-arch=corei7 --with-cpu=corei7 --prefix=/usr/8.0.0 --enable-clocale=gnu
--with-system-zlib --enable-shared --with-demangler-in-ld --enable-libmpx
--with-fpmath=sse

[Bug target/83781] [8 Regression] Bootstrap failed on x86

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Created attachment 43093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43093=edit
x86_64-linux tests summary.

My x864_64 bootstrap and regression test run of the patch succeeded with the
attached test summary.  Let me quickly retry with the top of trunk and look
into the warning.

[Bug c/83782] New: Inconsistent address for hidden ifunc in a shared library

[rafael.espindola at gmail dot com]

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

Bug ID: 83782
   Summary: Inconsistent address for hidden ifunc in a shared
library
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael.espindola at gmail dot com
  Target Milestone: ---

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

If a function with hidden visibility is implemented with an ifunc, different
translation units have different opinions as to what its address is.

The translation unit implementing the function gets its address with

movqfoo@GOTPCREL(%rip), %rax

That is, it finds the address of the actual function after it is selected.

Any translation unit will use

leaqfoo(%rip), %rax

which the linker translates to the address of the plt.

The net result is that the attached program finds two addresses for the same
function:

$ ./t
0x7fc5f331360a 0x7fc5f3313510

Gives the desire to allow ifuncs to be used by changing just the implementation
(not the declaration), I think the only solution is to use the plt address in
both translation units.

[Bug c++/83778] [8 regression] g++.dg/ext/altivec-cell-2.C fails starting with r256448

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Presumably we should simply strip the location from arg, though there are some
places with:

  /* Call get_element_number to validate arg1 if it is a constant.  */
  if (TREE_CODE (arg1) == INTEGER_CST)
(void) get_element_number (TREE_TYPE (arg0), arg1);

which suggests any such stripping needs to happen there.

[Bug c++/83778] [8 regression] g++.dg/ext/altivec-cell-2.C fails starting with r256448

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
It does look like an issue with r256448, but I haven't been able to reproduce
it here yet.

There are 3 in-tree copies of get_element_number, in 3 backends; each has 2
users per backend; they all look like:

static int
get_element_number (tree vec_type, tree arg)
{
  unsigned HOST_WIDE_INT elt, max = TYPE_VECTOR_SUBPARTS (vec_type) - 1;

  if (!tree_fits_uhwi_p (arg)
  || (elt = tree_to_uhwi (arg), elt > max))
{
  error ("selector must be an integer constant in the range 0..%wi", max);
  return 0;
}

  return elt;
}

which is going to fail if a location wrapper node around a INTEGER_CST is
passed for ARG, rather than a plain INTEGER_CST.

[Bug fortran/79383] USE statement error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
The attached code compiles with both 7-branch an trunk.
When the resulting excutable is run I get 15.10 on output.
Is this the expected behavior?

[Bug target/83781] [8 Regression] Bootstrap failed on x86

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
(In reply to H.J. Lu from comment #0)
> 
> r256454 is OK and r25646 failed. It may be caused by r256457.

Oops. r256463 failed.

[Bug target/83781] [8 Regression] Bootstrap failed on x86

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, diagnostic
 Target||x86_64-linux-gnu
  Component|c   |target
   Target Milestone|--- |8.0

[Bug c/83781] New: [8 Regression] Bootstrap failed on x86

[hjl.tools at gmail dot com]

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

Bug ID: 83781
   Summary: [8 Regression] Bootstrap failed on x86
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

I got

trunk/gcc/hsa-dump.c
../../src-trunk/gcc/hsa-dump.c: In function ‘void dump_hsa_symbol(FILE*,
hsa_symbol*)’:
../../src-trunk/gcc/hsa-dump.c:784:21: error: ‘%s’ directive writing up to 71
bytes into a region of size 62 [-Werror=format-overflow=]
   sprintf (buf, "__%s_%i", hsa_seg_name (symbol->m_segment),
 ^
../../src-trunk/gcc/hsa-dump.c:784:15: note: ‘sprintf’ output between 5 and 86
bytes into a destination of size 64
   sprintf (buf, "__%s_%i", hsa_seg_name (symbol->m_segment),
   ^~
 symbol->m_name_number);

and

../../src-trunk/gcc/config/i386/i386.c: In function 'const char*
output_set_got(rtx, rtx)':
../../src-trunk/gcc/config/i386/i386.c:10653:20: error: '%s' directive writing
up to 323 bytes into a region of size 13 [-Werror=format-overflow=]
 sprintf (name, "__x86.get_pc_thunk.%s", reg_names[regno]);
^~~
../../src-trunk/gcc/config/i386/i386.c:10653:13: note: 'sprintf' output between
20 and 343 bytes into a destination of size 32
 sprintf (name, "__x86.get_pc_thunk.%s", reg_names[regno]);
 ^

r256454 is OK and r25646 failed. It may be caused by r256457.

[Bug c++/83780] New: False positive alignment error with -fsanitize=undefined with virtual base

[securesneakers at gmail dot com]

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

Bug ID: 83780
   Summary: False positive alignment error with
-fsanitize=undefined with virtual base
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: securesneakers at gmail dot com
  Target Milestone: ---

Created attachment 43091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43091=edit
Minimal example that reproduces the issue

Attached program generates false misalignment errors when compiled with
-fsanitize=undefined

$ g++ --version
g++ (GCC) 7.2.1 20171224

$ uname -s -m
Linux x86_64

$ g++ -std=c++11 -O2 -fsanitize=undefined minimal.cpp && ./a.out
minimal.cpp:9:8: runtime error: constructor call on misaligned address
0x7ffdd1e1e658 for type 'struct Base2', which requires 16 byte alignment

Attached example contains following hierarchy:

struct alignas(16) Base1 { };
struct Base2 : virtual Base1 { };
struct Base3 : virtual Base2 { };

alignof(Base2) is set to 16 due to alignment of its base class. But when Base3
is instantiated, Base2 is placed with alignment of 8 as it should be according
to Itanium C++ ABI (due to its non-virtual alignment being equal 8):
https://refspecs.linuxfoundation.org/cxxabi-1.75.html#class-types. Yet
sanitizer complains about alignment not being 16.

Seems that sanitizer checks address using "normal" alignment when "non-virtual
alignment" should be used.

[Bug middle-end/83721] [8 Regression] ICE: in generic_overlap, at gimple-ssa-warn-restrict.c:821

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #2 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #1)
> Matthias, can you reconfirm this is still a problem after r256321?  I
> committed a fix from Martin S last night that should have fixed this.

Confirmed that r256272 exhibits the ICE on i686-linux-gnu, and that r256321
fixes the regression.

Closing.

[Bug c++/83779] Trivial bounds error not detected with -fbounds-check

[w6ws at earthlink dot net]

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

--- Comment #2 from Walter Spector  ---
Ah.  Thank you.

[Bug fortran/68241] [meta-bug] [F03] Deferred-length character

[kargl at gcc dot gnu.org]

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

Bug 82367 Summary: ICE with deferred length string allocate on non-deferred 
length argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82367

   What|Removed |Added

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

[Bug fortran/82367] ICE with deferred length string allocate on non-deferred length argument

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks for the bug report.

[Bug fortran/82367] ICE with deferred length string allocate on non-deferred length argument

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jan 10 23:55:00 2018
New Revision: 256467

URL: https://gcc.gnu.org/viewcvs?rev=256467=gcc=rev
Log:
2018-01-10  Steven G. Kargl  

PR fortran/82367
* resolve.c (resolve_allocate_expr): Check for NULL pointer.

2018-01-10  Steven G. Kargl  

PR fortran/82367
* gfortran.dg/deferred_character_18.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/deferred_character_18.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/resolve.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #2 from Ian Lance Taylor  ---
This does look like a middle-end bug, though.  That revision had a lot of Go
changes, but no significant changes to the compiler.  So we are passing
different Go code to the compiler, and probably some of the different code is
triggering this bug.

[Bug fortran/82367] ICE with deferred length string allocate on non-deferred length argument

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jan 10 23:41:48 2018
New Revision: 256466

URL: https://gcc.gnu.org/viewcvs?rev=256466=gcc=rev
Log:
2018-01-10  Steven G. Kargl  

PR fortran/82367
* resolve.c (resolve_allocate_expr): Check for NULL pointer.

2018-01-10  Steven G. Kargl  

PR fortran/82367
* gfortran.dg/deferred_character_18.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/deferred_character_18.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/82367] ICE with deferred length string allocate on non-deferred length argument

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jan 10 23:26:15 2018
New Revision: 256464

URL: https://gcc.gnu.org/viewcvs?rev=256464=gcc=rev
Log:
2018-01-10  Steven G. Kargl  

PR fortran/82367
* resolve.c (resolve_allocate_expr): Check for NULL pointer.

2018-01-10  Steven G. Kargl  

PR fortran/82367
* gfortran.dg/deferred_character_18.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/deferred_character_18.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||iant at google dot com,
   ||seurer at gcc dot gnu.org

--- Comment #1 from seurer at gcc dot gnu.org ---
Note that this started with r256365 which had a bunch of go patches.

[Bug fortran/82367] ICE with deferred length string allocate on non-deferred length argument

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

[Bug fortran/83093] ICE in fold_convert_loc, at fold-const.c:2266

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks for bug report.

[Bug fortran/83093] ICE in fold_convert_loc, at fold-const.c:2266

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jan 10 22:50:28 2018
New Revision: 256461

URL: https://gcc.gnu.org/viewcvs?rev=256461=gcc=rev
Log:
2018-01-10 Steven G. Kargl  

Backport from trunk
PR fortran/83093
* resolve.c (resolve_charlen): Check the type of cl->length
after resolution.

2018-01-10  Steven G. Kargl  

Backport from trunk
PR fortran/83093
* gfortran.dg/allocate_with_typespec_7.f90: New test.

Added:
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/allocate_with_typespec_7.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/resolve.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/83779] Trivial bounds error not detected with -fbounds-check

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The manual says:

"This is currently only supported by the Fortran front end, where this option
defaults to false."

[Bug fortran/83093] ICE in fold_convert_loc, at fold-const.c:2266

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jan 10 22:35:00 2018
New Revision: 256459

URL: https://gcc.gnu.org/viewcvs?rev=256459=gcc=rev
Log:
2018-01-10 Steven G. Kargl  

Backport from trunk
PR fortran/83093
* resolve.c (resolve_charlen): Check the type of cl->length
after resolution.

2018-01-10  Steven G. Kargl  

Backport from trunk
PR fortran/83093
* gfortran.dg/allocate_with_typespec_7.f90: New test.

Added:
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/allocate_with_typespec_7.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/83779] New: Trivial bounds error not detected with -fbounds-check

[w6ws at earthlink dot net]

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

Bug ID: 83779
   Summary: Trivial bounds error not detected with -fbounds-check
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w6ws at earthlink dot net
  Target Milestone: ---

Does -fbounds-check do anything useful with C/C++ code?  The following trivial
code does not trigger any error at run time.  (Note: I added the static
attribute because otherwise this simple example does trigger a stack smash
detected message after the program completes.):

wws@w6ws-4:/tmp$ cat bck.c
#include 

int main () {

  static int array1[20];

  for (int i=0; i<25; i++)
array1[i] = i;

  printf ("done!\n");
}
wws@w6ws-4:/tmp$ g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

wws@w6ws-4:/tmp$ g++ -g -fbounds-check bck.c
wws@w6ws-4:/tmp$ a.out
done!
wws@w6ws-4:/tmp$ gcc -g -fbounds-check bck.c
wws@w6ws-4:/tmp$ a.out
done!
wws@w6ws-4:/tmp$

[Bug c++/83778] New: [8 regression] g++.dg/ext/altivec-cell-2.C fails starting with r256448

[seurer at gcc dot gnu.org]

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

Bug ID: 83778
   Summary: [8 regression] g++.dg/ext/altivec-cell-2.C fails
starting with r256448
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Not sure if the test case needs updating or if the revision has a problem.

Executing on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++8/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++8/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++98 -maltivec  -S   -o altivec-cell-2.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++8/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++8/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -maltivec -S -o altivec-cell-2.s
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C: In
function 'int f4(__vector(4) int)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C:36:22:
error: selector must be an integer constant in the range 0..3
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C: In
function 'int g8(__vector(8) short int)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C:79:22:
error: selector must be an integer constant in the range 0..7
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C: In
function 'int f4(__vector(4) int)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C:36:22:
error: selector must be an integer constant in the range 0..3
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C: In
function 'int g8(__vector(8) short int)':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C:79:22:
error: selector must be an integer constant in the range 0..7

FAIL: g++.dg/ext/altivec-cell-2.C  -std=gnu++98 (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C:36:22:
error: selector must be an integer constant in the range 0..3
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C:79:22:
error: selector must be an integer constant in the range 0..7

Executing on host:
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++8/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++8/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++11 -maltivec  -S   -o altivec-cell-2.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++8/../../xg++
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++8/../../
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++11 -maltivec -S -o altivec-cell-2.s
/home/seurer/gcc/gcc-trunk/gcc/testsuite/g++.dg/ext/altivec-cell-2.C: In
function 'int f4(__vector(4) int)':

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-10
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Peter Bergner  ---
Going through the kernel cputable.c file and comparing it to rs6000-cpus.def, I
think the name translation should like:

These kernel AT_PLATFORM names can be used as is:
  .platform = "powerpc",
  .platform = "power3",
  .platform = "power4",
  .platform = "power5",
  .platform = "power5+",
  .platform = "power6",
  .platform = "power6x",
  .platform = "power7",
  .platform = "power8",
  .platform = "power9",

This kernel AT_PLATFORM name should strip the '+' off:
  .platform = "power7+", -> "power7"

These kernel AT_PLATFORM names should strip the 'ppc' prefix off:
  .platform = "ppc970", -> "970"
  .platform = "ppc601", -> "601"
  .platform = "ppc603", -> "603"
  .platform = "ppc604", -> "604"
  .platform = "ppc750", -> "750"
  .platform = "ppc7400", -> "7400"
  .platform = "ppc7450", -> "7450"
  .platform = "ppc823", -> "823"
  .platform = "ppc403", -> "403"
  .platform = "ppc8540", -> "8540"
  .platform = "ppc8548", -> "8548"
  .platform = "ppce5500", -> "e5500"
  .platform = "ppce6500", -> "e6500"

These kernel AT_PLATFORM names should strip their prefix and suffix off:
  .platform = "ppc440gp", -> "440"
  .platform = "ppc-cell-be", -> "cell"

These kernel AT_PLATFORM names should strip the 'ppc' prefix off, as
well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
  .platform = "ppc405", -> "405" | "405fp"
  .platform = "ppc440", -> "440" | "440fp"

This kernel AT_PLATFORM name should strip the 'ppc' prefix off, change
470 to 476 as well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
  .platform = "ppc470", -> "476" | "476fp"

This kernel AT_PLATFORM name should strip the 'ppc' prefix off, as
well as test the AT_HWCAP for PPC_FEATURE_64::
  .platform = "ppce500mc", -> "e500mc" | "e500mc64"

These kernel AT_PLATFORM names do not seem to have an equivalent
rs6000-cpus.def entry, so we probably should just treat them as
unknown/non-existent names:
  .platform = "pa6t",
  .platform = "ppc5554",

I will take a stab at adding this name translation, which should also fix
PR83743.

I do question though, whether we should test the AT_HWCAP bits or not.  Just
because we're on, say a 476fp system, doesn't mean the toolchain and libraries
are compiled with FP support.  Thoughts anyone?

[Bug tree-optimization/83671] Fix for false positive reported by -Wstringop-overflow does not work at -O1

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
Patch committed in r256457.

[Bug tree-optimization/83671] Fix for false positive reported by -Wstringop-overflow does not work at -O1

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Jan 10 21:40:14 2018
New Revision: 256457

URL: https://gcc.gnu.org/viewcvs?rev=256457=gcc=rev
Log:
PR tree-optimization/83671 - Fix for false positive reported by
-Wstringop-overflow does not work with inlining

gcc/testsuite/ChangeLog:

PR tree-optimization/83671
* gcc.dg/strlenopt-40.c: New test.
* gcc.dg/strlenopt-41.c: New test.

gcc/ChangeLog:

PR tree-optimization/83671
* builtins.c (c_strlen): Unconditionally return zero for the empty
string.
Use -Warray-bounds for warnings.
* gimple-fold.c (get_range_strlen): Handle non-constant lengths
for non-constant array indices with COMPONENT_REF, arrays of
arrays, and pointers to arrays.
(gimple_fold_builtin_strlen): Determine and set length range for
non-constant character arrays.


Added:
trunk/gcc/testsuite/gcc.dg/strlenopt-40.c
trunk/gcc/testsuite/gcc.dg/strlenopt-41.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/string1.C

[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning

[aldyh at gcc dot gnu.org]

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

--- Comment #22 from Aldy Hernandez  ---
Author: aldyh
Date: Wed Jan 10 21:39:20 2018
New Revision: 256456

URL: https://gcc.gnu.org/viewcvs?rev=256456=gcc=rev
Log:
PR middle-end/81897
* tree-ssa-uninit.c (convert_control_dep_chain_into_preds): Skip
empty blocks.

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

[Bug c++/83777] New: Invalid dependent initialization of a static data member.

[Zahira.Ammarguellat at intel dot com]

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

Bug ID: 83777
   Summary: Invalid dependent initialization of a static data
member.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Zahira.Ammarguellat at intel dot com
  Target Milestone: ---

Reproducer:

template  class C
{
  static const int BlockSize = T::M;
  public:
static const int type = 1;
};

int foo() { return C::type == 1; }

This should be returning an error.

[Bug fortran/83093] ICE in fold_convert_loc, at fold-const.c:2266

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jan 10 21:31:43 2018
New Revision: 256455

URL: https://gcc.gnu.org/viewcvs?rev=256455=gcc=rev
Log:
2018-01-10 Steven G. Kargl  

PR fortran/83093
* resolve.c (resolve_charlen): Check the type of cl->length
after resolution.

2018-01-10  Steven G. Kargl  

PR fortran/83093
* gfortran.dg/allocate_with_typespec_7.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83776] [5/6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to work||4.5.4
Summary|missing -Warray-bounds  |[5/6/7/8 Regression]
   |indexing past the end of a  |missing -Warray-bounds
   |string literal  |indexing past the end of a
   ||string literal
  Known to fail||4.6.4, 4.7.4, 4.8.4, 4.9.4,
   ||5.5.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
It turns out that GCC 4.5 was able to diagnose all three instances but that
ability was lost with r164688 so this is a regression, albeit an ancient one.

r164688 | hubicka | 2010-09-28 12:28:39 -0400 (Tue, 28 Sep 2010) | 5 lines

* tree-ssa-ccp.c (fold_ctor_reference): New function.
(fold_const_aggregate_ref): Use it.
* fold-const.c (canonicalize_constructor_val): Check that we don't fold
into external static.

[Bug tree-optimization/83776] New: missing -Warray-bounds indexing past the end of a string literal

[msebor at gcc dot gnu.org]

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

Bug ID: 83776
   Summary: missing -Warray-bounds indexing past the end of a
string literal
   Product: gcc
   Version: 8.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: ---

MEM_REF gets in the way of diagnosing -Warray-bounds in other cases where it's
quite difficult to deal with but it should be straightforward to diagnose the
cases where the operand is a string literal like in the test case below.

$ cat d.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout d.c
#define S "0123456789"

int f (void)
{
  return S[16];   // -Warray-bounds (good)
}

int g (void)
{
  const char *p = S + 16;   // missing -Warray-bounds
  return *p;// either here or above 
}

int h (void)
{
  const char *p = S;
  return p[16];   // missing -Warray-bounds
}

d.c: In function ‘f’:
d.c:5:11: warning: array subscript 16 is above array bounds of ‘char[11]’
[-Warray-bounds]
   return S[16];   // -Warray-bounds (good)
   ^

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

f ()
{
  char _1;
  int _2;

   [local count: 1073741825]:
  _1 = "0123456789"[16];
  _2 = (int) _1;
  return _2;

}



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

g ()
{
  char _1;
  int _3;

   [local count: 1073741825]:
  _1 = MEM[(const char *)"0123456789" + 16B];
  _3 = (int) _1;
  return _3;

}



;; Function h (h, funcdef_no=4, decl_uid=1957, cgraph_uid=2, symbol_order=2)

h ()
{
  char _3;
  int _4;

   [local count: 1073741825]:
  _3 = MEM[(const char *)"0123456789" + 16B];
  _4 = (int) _3;
  return _4;

}

[Bug rtl-optimization/83575] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[bergner at gcc dot gnu.org]

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

--- Comment #13 from Peter Bergner  ---
Author: bergner
Date: Wed Jan 10 20:49:36 2018
New Revision: 256453

URL: https://gcc.gnu.org/viewcvs?rev=256453=gcc=rev
Log:
gcc/
PR target/83399
* config/rs6000/rs6000.c (print_operand) <'y'>: Use
VECTOR_MEM_ALTIVEC_OR_VSX_P.
* config/rs6000/vsx.md (*vsx_le_perm_load_ for VSX_D): Use
indexed_or_indirect_operand predicate.
(*vsx_le_perm_load_ for VSX_W): Likewise.
(*vsx_le_perm_load_v8hi): Likewise.
(*vsx_le_perm_load_v16qi): Likewise.
(*vsx_le_perm_store_ for VSX_D): Likewise.
(*vsx_le_perm_store_ for VSX_W): Likewise.
(*vsx_le_perm_store_v8hi): Likewise.
(*vsx_le_perm_store_v16qi): Likewise.
(eight unnamed splitters): Likewise.

gcc/testsuite/
PR target/83399
* gcc.target/powerpc/pr83399.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr83399.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug ipa/60871] [4.9 Regression] internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1510

[neil.kindlon at jax dot org]

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

--- Comment #21 from Neil Kindlon  ---
Hi,
I regret to report that I encountered what appears to be a similar error in
gcc version 7.1.0. This is my first bug report here, so please correct me if
this information is not helpful or incomplete.

system type:
LSB Version:   
:base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:CentOS release 6.5 (Final)
Release:6.5
Codename:   Final

Linux version 2.6.32-696.18.7.el6.x86_64 (mockbu...@c1bl.rdu2.centos.org) (gcc
version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC) ) #1 SMP Thu Jan 4 17:31:22 UTC
2018


gcc build options:
 $ ./configure --prefix=/opt/compsci/gcc/7.1.0 --disable-multilib

Error:
$ make install

/projects/kindln/share/utils/jax-egtk/bio-pp/bpp-phyl/src/Bpp/Phyl/Model/Codon/AbstractCodonSubstitutionModel.cpp:
In constructor
‘bpp::AbstractCodonSubstitutionModel::AbstractCodonSubstitutionModel(const
bpp::GeneticCode*, bpp::NucleotideSubstitutionModel*, const string&, bool)’:
/projects/kindln/share/utils/jax-egtk/bio-pp/bpp-phyl/src/Bpp/Phyl/Model/Codon/AbstractCodonSubstitutionModel.cpp:47:1:
internal compiler error: in possible_polymorphic_call_targets, at
ipa-devirt.c:1557
 AbstractCodonSubstitutionModel::AbstractCodonSubstitutionModel(
 ^
0x869deb possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, int*)
../../gcc/ipa-devirt.c:1557
0x83cf91 possible_polymorphic_call_targets
../../gcc/ipa-utils.h:142
0x83cf91 gimple_fold_call
../../gcc/gimple-fold.c:1127
0x83cf91 fold_stmt_1
../../gcc/gimple-fold.c:1302
0xab6d3a substitute_and_fold(tree_node* (*)(tree_node*), bool
(*)(gimple_stmt_iterator*), bool)
../../gcc/tree-ssa-propagate.c:1200
0xa58b88 fini_copy_prop
../../gcc/tree-ssa-copy.c:587
0xa58b88 execute_copy_prop
../../gcc/tree-ssa-copy.c:631
0xa58b88 execute
../../gcc/tree-ssa-copy.c:669
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: ***
[src/CMakeFiles/bpp-phyl-shared.dir/Bpp/Phyl/Model/Codon/AbstractCodonSubstitutionModel.cpp.o]
Error 1
make[1]: *** [src/CMakeFiles/bpp-phyl-shared.dir/all] Error 2
make: *** [all] Error 2

In my last comment I attached the .ii.bz2 temporary file generated while
attempting to compile this. 
I was attempting to build the bpp-phyl library in Bio++, which requires first
building bpp-core.I'm sorry to just paste the github sites, but there were many
files, and I'm only just starting to look at the code base.

https://github.com/BioPP/bpp-core
https://github.com/BioPP/bpp-phyl

git clone g...@github.com:BioPP/bpp-core.git
git clone g...@github.com:BioPP/bpp-phyl.git

I followed the default instructions in each for cmake and make install, and got
the error above.

This was the constructor:
AbstractCodonSubstitutionModel::AbstractCodonSubstitutionModel(
  const GeneticCode* gCode,
  NucleotideSubstitutionModel* pmod,
  const std::string& prefix,
  bool paramRates) :
  AbstractParameterAliasable(prefix),
  AbstractWordSubstitutionModel(gCode->getSourceAlphabet(), new
CanonicalStateMap(gCode->getSourceAlphabet(), false), prefix),
  hasParametrizedRates_(paramRates),
  gCode_(gCode)
{
  enableEigenDecomposition(true);

  size_t i;
  for (i = 0; i < 3; i++)
  {
VSubMod_.push_back(pmod);
VnestedPrefix_.push_back(pmod->getNamespace());
  }

  pmod->setNamespace(prefix + "123_" + VnestedPrefix_[0]);
  pmod->enableEigenDecomposition(0);

  addParameters_(pmod->getParameters());

  Vrate_.resize(3);
  for (i = 0; i < 3; i++)
  {
Vrate_[i] = 1.0 / 3;
  }


  if (hasParametrizedRates_)
  {
// relative rates
for (i = 0; i < 2; i++)
{
  addParameter_(new Parameter(prefix + "relrate" + TextTools::toString(i +
1), 1.0 / static_cast(3 - i), ::PROP_CONSTRAINT_EX));
}
  }
}

I hope this is helpful. If not, please let me know what other information is
required.
Thanks,
Neil

[Bug target/83761] bfin: ICE: in require, at machmode.h:292

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Could you attached preprocessed source?

[Bug other/83508] [8 regression][arm] c-c++-common/Wrestrict.c fails since r255836

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00808.html

[Bug ipa/60871] [4.9 Regression] internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1510

[neil.kindlon at jax dot org]

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

Neil Kindlon  changed:

   What|Removed |Added

 CC||neil.kindlon at jax dot org

--- Comment #20 from Neil Kindlon  ---
Created attachment 43090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43090=edit
gcc temp file bug 60871

This is the temp code generated during the compilation that hit this error:
"possible_polymorphic_call_targets, at ipa-devirt.c:1557"

[Bug c++/43486] Preserve variable-use locations

[dmalcolm at gcc dot gnu.org]

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

--- Comment #12 from David Malcolm  ---
(In reply to David Malcolm from comment #11)
> Author: dmalcolm
> Date: Wed Jan 10 19:40:55 2018
> New Revision: 256448
> 
> URL: https://gcc.gnu.org/viewcvs?rev=256448=gcc=rev
> Log:
> Preserving locations for variable-uses and constants (PR c++/43486)

This patch is a step towards fixing this bug, but we're not there yet:

The patch adds machinery for adding location wrapper nodes for those
expressions that don't have them, and adds such wrappers to the C++ FE for
callsite arguments and at a few other places. This is a minimal approach, which
improves various diagnostics in the C++ FE, but in theory we should add
wrappers throughout the C++ FE for *all* uses-of-decls and uses-of-constants. 
See:
  https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01588.html
for an earlier work-in-progress attempt at this (probably bit-rotted by now).

Similarly, the patch doesn't add any wrapper nodes to other frontends, in
particular, the C FE.

Finally, I believe, all of these wrappers are discarded at some point at or
before gimplification, so it doesn't help the middle-end yet; we'd need some
way to retain the location information there.

[Bug c++/43486] Preserve variable-use locations

[dmalcolm at gcc dot gnu.org]

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

--- Comment #11 from David Malcolm  ---
Author: dmalcolm
Date: Wed Jan 10 19:40:55 2018
New Revision: 256448

URL: https://gcc.gnu.org/viewcvs?rev=256448=gcc=rev
Log:
Preserving locations for variable-uses and constants (PR c++/43486)

This patch implements location wrapper nodes, preserving source locations
of the uses of variables and constants in various places in the
C++ frontend: at the arguments at callsites, and for typeid, alignof,
sizeof, and offsetof.

For example, it allows the C++ FE to underline the pertinent argument
for mismatching calls, for such expressions, improving:

extern int callee (int one, const char *two, float three);

int caller (int first, int second, float third)
{
  return callee (first, second, third);
}

from

test.cc: In function 'int caller(int, int, float)':
test.cc:5:38: error: invalid conversion from 'int' to 'const char*'
[-fpermissive]
   return callee (first, second, third);
  ^
test.cc:1:41: note:   initializing argument 2 of 'int callee(int, const char*,
float)'
 extern int callee (int one, const char *two, float three);
 ^~~

to:

test.cc: In function 'int caller(int, int, float)':
test.cc:5:25: error: invalid conversion from 'int' to 'const char*'
[-fpermissive]
   return callee (first, second, third);
 ^~
test.cc:1:41: note:   initializing argument 2 of 'int callee(int, const char*,
float)'
 extern int callee (int one, const char *two, float three);
 ^~~

This is the combination of the following patches:

  "[PATCH 01/14] C++: preserve locations within build_address"
 https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00883.html

  "[PATCH v2.4 of 02/14] Support for adding and stripping location_t wrapper
nodes"
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00591.html

  "[PATCH] Eliminate location wrappers in tree_nop_conversion/STRIP_NOPS"
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01330.html

  "[PATCH v4 of 03/14] C++: add location_t wrapper nodes during parsing
(minimal impl)"
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00660.html

  "[PATCH 04/14] Update testsuite to show improvements"
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00891.html

  "[v3 of 05/14] C++: handle locations wrappers when calling warn_for_memset"
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01378.html

  "[PATCH 07/14] reject_gcc_builtin: strip any location wrappers"
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00886.html

  "[v3 of PATCH 08/14] cp/tree.c: strip location wrappers in lvalue_kind"
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01433.html

  "[PATCH 09/14] Strip location wrappers in null_ptr_cst_p"
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00888.html

  "[PATCH 11/14] Handle location wrappers in string_conv_p"
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00890.html

  "[PATCH 12/14] C++: introduce null_node_p"
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00894.html

  "[v3 of PATCH 13/14] c-format.c: handle location wrappers"
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01494.html

  "[PATCH 14/14] pp_c_cast_expression: don't print casts for location wrappers"
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00893.html

  "[v3 of PATCH 15/14] Use fold_for_warn in get_atomic_generic_size"
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01380.html

  "[PATCH] Add selftest for "fold_for_warn (error_mark_node)""
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01385.html

gcc/c-family/ChangeLog:
PR c++/43486
* c-common.c: Include "selftest.h".
(get_atomic_generic_size): Perform the test for integral type
before the range test for any integer constant, fixing indentation
of braces.  Call fold_for_warn before testing for an INTEGER_CST.
(reject_gcc_builtin): Strip any location wrapper from EXPR.
(selftest::test_fold_for_warn): New function.
(selftest::c_common_c_tests): New function.
(selftest::c_family_tests): Call it, and
selftest::c_pretty_print_c_tests.
* c-common.h (selftest::c_pretty_print_c_tests): New decl.
* c-format.c (check_format_arg): Convert VAR_P check to a
fold_for_warn.
* c-pretty-print.c: Include "selftest.h".
(pp_c_cast_expression): Don't print casts for location wrappers.
(selftest::assert_c_pretty_printer_output): New function.
(ASSERT_C_PRETTY_PRINTER_OUTPUT): New macro.
(selftest::test_location_wrappers): New function.
(selftest::c_pretty_print_c_tests): New function.
* c-warn.c (warn_for_memset): Call fold_for_warn on the arguments.

gcc/cp/ChangeLog:
PR c++/43486
* call.c (null_ptr_cst_p): Strip location wrappers when
converting from '0' to a pointer type in C++11 onwards.
(conversion_null_warnings): Replace 

[Bug go/83308] Missing platform definitions for SH in libgo

[ian at airs dot com]

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

--- Comment #20 from Ian Lance Taylor  ---
This will be in GCC 8.

Backports to GCC 7 are fine with me but I'm not going to do them myself.

[Bug go/83308] Missing platform definitions for SH in libgo

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #19 from John Paul Adrian Glaubitz  ---
(In reply to Ian Lance Taylor from comment #18)
> OK, the SH support patch is committed, and the exp directory has been
> removed.
> 
> Is there anything else to do here?

I don't think so. But it would be nice if this could get backported to gcc-7 or
at least gcc-8.

Thanks,
Adrian

[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Steve Ellcey from comment #7
> pr83081.f90 looks like a new test so it may not actually be a regression
> related to this patch, but the first two are.  pr79041-2 generates:
> 
> t:
>   mov x0, 0
>   mov x1, 65536
>   ret
> 
> with the patch rather than:
> 
> t:
>   adr x0, .LC0
>   ldp x0, x1, [x0]
>   ret
>   .size   t, .-t
>   .align  4
> .LC0:
>   .xword  0
>   .xword  65536

The first code generation is better than doing a load.  That is doing two mov
is better than doing an adr/ldp in terms of size and even ldp could miss the
cache  while the two mov are independent and can most likely be executed on the
same pipeline.

[Bug target/83514] ABRT in arm_declare_function_name passing a null pointer to std::string

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
That is a very bad decision, even the cc1/cc1plus processes shouldn't ICE on
bad inputs.  It doesn't really matter what exact arch string it defaults on, it
may be something chosen during configure or just hardcoded default, but just
segfaulting is a really bad idea.

[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442

[ygribov at gcc dot gnu.org]

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

--- Comment #8 from Yury Gribov  ---
(In reply to Jakub Jelinek from comment #7)
> Any further progress?  I see you've posted something, but no further
> follow-ups from you nor Segher.

Jakub, I didn't contribute for few months now due to health issues.  I checked
with Segher offline and he said we can push this to February (if noone else
claims otherwise).

[Bug target/83775] Segfault in arm_declare_function_name()

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83514

--- Comment #2 from Martin Sebor  ---
See also 83514 for a report of the same ICE.

[Bug go/83308] Missing platform definitions for SH in libgo

[ian at airs dot com]

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

--- Comment #18 from Ian Lance Taylor  ---
OK, the SH support patch is committed, and the exp directory has been removed.

Is there anything else to do here?

[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063

[sje at gcc dot gnu.org]

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

--- Comment #7 from Steve Ellcey  ---
I tested the patch on my aarch64 box, I got three regressions:

FAIL: gcc.target/aarch64/pr78733.c scan-assembler adr
FAIL: gcc.target/aarch64/pr79041-2.c scan-assembler adr
FAIL: gfortran.fortran-torture/compile/pr83081.f90,  -O3 -g   (internal
compiler error)

pr83081.f90 looks like a new test so it may not actually be a regression
related to this patch, but the first two are.  pr79041-2 generates:

t:
mov x0, 0
mov x1, 65536
ret

with the patch rather than:

t:
adr x0, .LC0
ldp x0, x1, [x0]
ret
.size   t, .-t
.align  4
.LC0:
.xword  0
.xword  65536

[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning

[law at redhat dot com]

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

--- Comment #21 from Jeffrey A. Law  ---
I'm pretty sure the testcase from c#16 is a different underlying issue and an
DUP of an existing BZ.  Note the ASMs.  Jump threading is (overly) conservative
when it encounters an ASM on the path and simply refuses to thread the path.

As a result we leave unexecutable paths in the CFG leading to the warning.

[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning

[aldyh at gcc dot gnu.org]

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

--- Comment #20 from Aldy Hernandez  ---
(In reply to Aldy Hernandez from comment #18)
> (In reply to Arnd Bergmann from comment #16)
> > Created attachment 43056 [details]
> > linux/net/ipv6/route.c, preprocessed and compressed
> > 
> > To test the patch, I reverted the workaround that was added to the kernel
> > when I originally reported this. Unfortunately the warning is still there,
> > only the reduced version is fixed. I attached the preprocessed source now,
> > test with
> > 
> > $ x86_64-linux-gcc-8.0.0 -fno-strict-aliasing -Wall -O2 -Wno-pointer-sign -c
> > route-1.i
> > /git/arm-soc/net/ipv6/route.c: In function 'inet6_rtm_getroute':
> > /git/arm-soc/net/ipv6/route.c:4350:9: warning: 'dst' may be used
> > uninitialized in this function [-Wmaybe-uninitialized]
> >goto errout;
> >  ^~
> >   }
> > 
> > Reducing this with the latest gcc-8.0.0 snapshot gave me
> > 
> > enum { true } fn1();
> > int inet6_rtm_getroute_iif, inet6_rtm_getroute_rt, inet6_rtm_getroute_rtm_0;
> > int *inet6_rtm_getroute___trans_tmp_8;
> > int fn2();
> > void fn3() {
> >   int *dst;
> >   _Bool fibmatch = inet6_rtm_getroute_rtm_0 & 2;
> >   if (inet6_rtm_getroute_iif) {
> > if (!fibmatch)
> >   dst = inet6_rtm_getroute___trans_tmp_8;
> > static _Bool __warned;
> > fn2() && __warned &();
> > __warned = true;
> >   } else if (!fibmatch)
> > dst = 0;
> >   if (fibmatch)
> > dst = 0;
> >   inet6_rtm_getroute_rt = *dst;
> > }
> 
> For both the reduced and full testcase in comment #16, I see this warning
> present in GCC 5, 6, 7, and 8 (mainline).  So this does not look like a
> regression in the recent past.
> 
> I also tested the reduced case in this comment for gcc4.5 (at least at
> r150051), and the warning is present there as well.  I didn't test the full
> testcase, as they were other warnings that muddled the waters in such
> ancient version.
> 
> If you feel this reduced case is still problematic, I think we should open a
> new PR, and mark it as a regression if you find a GCC far enough back that
> does not exhibit the warning.  If you can't find a GCC for which this has
> regressed, then at least mark it as an enhancement request.

FWIW, the reduced testcase in comment 16 is fixed by Andrew and mine's upcoming
work for the next release cycle (GCC 9).  Sorry :(.  So if you open a PR, feel
free to CC or assign it to me.  (not so for the test in comment 17).

[Bug fortran/82841] Segfault in gfc_simplify_transfer

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.  Closing.
Thanks for the bug report.

[Bug fortran/82841] Segfault in gfc_simplify_transfer

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jan 10 18:47:44 2018
New Revision: 256445

URL: https://gcc.gnu.org/viewcvs?rev=256445=gcc=rev
Log:
2018-01-10  Steven G. Kargl  

Backport r254555 from trunk
PR Fortran/82841
* gfortran.dg/transfer_simplify_11.f90: New test.


2018-01-10  Steven G. Kargl  

Backport r254555 from trunk
PR Fortran/82841
* simplify.c(gfc_simplify_transfer): Do not dereference a NULL pointer.
Unwrap a short line.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/transfer_simplify_11.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/simplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning

[aldyh at gcc dot gnu.org]

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

--- Comment #19 from Aldy Hernandez  ---
(In reply to Arnd Bergmann from comment #17)
> Created attachment 43057 [details]
> linux/drivers/scsi/lpfc/lpfc_bsg.c, preprocessed and compressed
> 
> A possibly related warning I just saw this week, with and without the gcc
> patch, and back to gcc-4.5+:
> 
> x86_64-linux-gcc-8.0.0 -fno-strict-aliasing -Wall -O2 -Wno-pointer-sign -m32
> -c -xc lpfc_bsg.i
> /git/arm-soc/drivers/scsi/lpfc/lpfc_bsg.c: In function
> 'lpfc_bsg_rport_els_cmp':
> /git/arm-soc/drivers/scsi/lpfc/lpfc_bsg.c:632:22: warning: 'bsg_reply' may
> be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> reduced to
> 8<
> long current_stack_pointer, lpfc_bsg_rport_els_cmp_rsp_0;
> long pv_irq_ops_1_0, pv_irq_ops_0_0;
> struct bsg_job {
>   void *reply;
> };
> struct fc_bsg_reply {
>   int reply_payload_rcv_len;
>   struct bsg_job set_job;
> } * lpfc_bsg_rport_els_cmp_dd_data;
> static void check(long v)
> {
>   if (v) {
> asm("");
> __builtin_unreachable();
>   }
> }
> void lpfc_bsg_rport_els_cmp(void) {
>   struct bsg_job *job;
>   struct fc_bsg_reply *bsg_reply;
>   job = _bsg_rport_els_cmp_dd_data->set_job;
>   if (job)
> bsg_reply = job->reply;
>   check(pv_irq_ops_0_0);
>   check(pv_irq_ops_1_0);
>   asm("" : "+r"(current_stack_pointer));
>   check(pv_irq_ops_0_0);
>   check(pv_irq_ops_1_0);
>   if (job) {
> if (lpfc_bsg_rport_els_cmp_rsp_0 == 0)
>   bsg_reply->reply_payload_rcv_len = 0;
> else if (lpfc_bsg_rport_els_cmp_rsp_0 == 1)
>   bsg_reply->reply_payload_rcv_len = 0;
>   }
> }
> >8
> This looked similar to the originally reported symptom in the source code.
> The reduced version looks quite a bit different, so no idea if this is
> something else entirely or not.

This is actually not a regression to gcc 4.5 because we didn't have
-Wmaybe-uninitialized warnings then.  You are testing gcc 4.5 with -Wall, which
is different to -Wall in recent GCC's, etc.  What you want to use is
-Wmaybe-uninitialized instead of -Wall to test at which point it regresses.  I
think this likely started happening when -Wmaybe-uninitialized was implemented.

However, I agree that this warning is annoying.  Would you mind opening a new
PR with an enhancement request for this?

[Bug target/83775] Segfault in arm_declare_function_name()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I'm seeing this in my 2 recently built cross-compilers from x86_64-linux to
arm*-linux-gnueabi too.  I think it is pretty much on any testcase.

[Bug fortran/82841] Segfault in gfc_simplify_transfer

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jan 10 18:44:12 2018
New Revision: 256444

URL: https://gcc.gnu.org/viewcvs?rev=256444=gcc=rev
Log:
2018-01-10  Steven G. Kargl  

Backport r254555 from trunk
PR Fortran/82841
* gfortran.dg/transfer_simplify_11.f90: New test.


2018-01-10  Steven G. Kargl  

Backport r254555 from trunk
PR Fortran/82841
* simplify.c(gfc_simplify_transfer): Do not dereference a NULL pointer.
Unwrap a short line.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/transfer_simplify_11.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/simplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
Does the kernel still need this workaround?  Shall we just add the option and
gradually add the checks?

[Bug middle-end/81897] [6/7 Regression] spurious -Wmaybe-uninitialized warning

[aldyh at gcc dot gnu.org]

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

--- Comment #18 from Aldy Hernandez  ---
(In reply to Arnd Bergmann from comment #16)
> Created attachment 43056 [details]
> linux/net/ipv6/route.c, preprocessed and compressed
> 
> To test the patch, I reverted the workaround that was added to the kernel
> when I originally reported this. Unfortunately the warning is still there,
> only the reduced version is fixed. I attached the preprocessed source now,
> test with
> 
> $ x86_64-linux-gcc-8.0.0 -fno-strict-aliasing -Wall -O2 -Wno-pointer-sign -c
> route-1.i
> /git/arm-soc/net/ipv6/route.c: In function 'inet6_rtm_getroute':
> /git/arm-soc/net/ipv6/route.c:4350:9: warning: 'dst' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>goto errout;
>  ^~
>   }
> 
> Reducing this with the latest gcc-8.0.0 snapshot gave me
> 
> enum { true } fn1();
> int inet6_rtm_getroute_iif, inet6_rtm_getroute_rt, inet6_rtm_getroute_rtm_0;
> int *inet6_rtm_getroute___trans_tmp_8;
> int fn2();
> void fn3() {
>   int *dst;
>   _Bool fibmatch = inet6_rtm_getroute_rtm_0 & 2;
>   if (inet6_rtm_getroute_iif) {
> if (!fibmatch)
>   dst = inet6_rtm_getroute___trans_tmp_8;
> static _Bool __warned;
> fn2() && __warned &();
> __warned = true;
>   } else if (!fibmatch)
> dst = 0;
>   if (fibmatch)
> dst = 0;
>   inet6_rtm_getroute_rt = *dst;
> }

For both the reduced and full testcase in comment #16, I see this warning
present in GCC 5, 6, 7, and 8 (mainline).  So this does not look like a
regression in the recent past.

I also tested the reduced case in this comment for gcc4.5 (at least at
r150051), and the warning is present there as well.  I didn't test the full
testcase, as they were other warnings that muddled the waters in such ancient
version.

If you feel this reduced case is still problematic, I think we should open a
new PR, and mark it as a regression if you find a GCC far enough back that does
not exhibit the warning.  If you can't find a GCC for which this has regressed,
then at least mark it as an enhancement request.

[Bug target/83775] New: Segfault in arm_declare_function_name()

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 83775
   Summary: Segfault in arm_declare_function_name()
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
For the following test-case:

#define STR "1234567"

const char str[] = STR;

char dst[10];

void copy_from_global_str (void)
{
  __builtin_strcpy (dst, str);

  if (__builtin_strlen (dst) != sizeof str - 1)
__builtin_abort ();
}

With arm-linux-gnueabihf-gcc -O2 I get the following ICE:
strlenopt-39.c: In function 'copy_from_global_str':
strlenopt-39.c:13:1: internal compiler error: Segmentation fault
 }
 ^
0xbc1f1f crash_signal
../../gcc/gcc/toplev.c:325
0xf4a5bb std::char_traits::length(char const*)
/usr/include/c++/6/bits/char_traits.h:267
0xf4a5bb std::__cxx11::basic_string::assign(char const*)
/usr/include/c++/6/bits/basic_string.h:1268
0xf4a5bb std::__cxx11::basic_string::operator=(char const*)
/usr/include/c++/6/bits/basic_string.h:605
0xf4a5bb arm_declare_function_name(_IO_FILE*, char const*, tree_node*)
../../gcc/gcc/config/arm/arm.c:30958
0xf4ad2d arm_asm_declare_function_name(_IO_FILE*, char const*, tree_node*)
../../gcc/gcc/config/arm/arm.c:19899
0xefd8fc assemble_start_function(tree_node*, char const*)
../../gcc/gcc/varasm.c:1880
0x87929f rest_of_handle_final
../../gcc/gcc/final.c:4549
0x87929f execute
../../gcc/gcc/final.c:4625

This happens because of following in arm_declare_function_name():
  /* Only update the assembler .arch string if it is distinct from the last
 such string we printed.  */
  std::string arch_to_print = targ_options->x_arm_arch_string;

In this case, targ_options->x_arm_arch_string is NULL and hence the above
error.
Does the following (untested) fix look OK ?

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 196aa6de1ac..868251a154c 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -30954,7 +30954,10 @@ arm_declare_function_name (FILE *stream, const char
*name, tree decl)

   /* Only update the assembler .arch string if it is distinct from the last
  such string we printed.  */
-  std::string arch_to_print = targ_options->x_arm_arch_string;
+  std::string arch_to_print;
+  if (targ_options->x_arm_arch_string)
+arch_to_print = targ_options->x_arm_arch_string;
+
   if (arch_to_print != arm_last_printed_arch_string)
 {
   std::string arch_name


Thanks,
Prathamesh

[Bug ipa/83178] [8 regression] g++.dg/ipa/devirt-22.C fail

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
We create an additional clone because the edge that brings the context
now satisfies maybe_hot_p and previously it didn't.  The reason is
that the caller (which is called sort) now has frequency
NODE_FREQUENCY_EXECUTED_ONCE whereas previously it was
NODE_FREQUENCY_UNLIKELY_EXECUTED.

sort in term is a static function called from an externally visible
update_sources with frequency NODE_FREQUENCY_NORMAL and looks like:

int *e;
void update_sources() {
  if (e) {
C f;
sort(f, b);
  }
}

I am not sure I understand why this should mean that sort is only
likely to be executed once but it does not seem to be any worse than
the previous value.  I'll prepare the patch adjusting the test.

[Bug tree-optimization/83774] New: ICE at -O3 with -Wall: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 83774
   Summary: ICE at -O3 with -Wall: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a very recent regression. 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20180110 (experimental) [trunk revision 256427] (GCC)
$
$ gcctk -O3 small.c
$ 
$ gcctk -O3 -Wall small.c
during GIMPLE pass: uninit
small.c: In function ‘main’:
small.c:6:5: internal compiler error: Segmentation fault
 int main ()
 ^~~~
0xc95c5f crash_signal
../../gcc-source-trunk/gcc/toplev.c:325
0xee3825 gimple_code
../../gcc-source-trunk/gcc/gimple.h:1677
0xee3825 is_gimple_call
../../gcc-source-trunk/gcc/gimple.h:2788
0xee3825 convert_control_dep_chain_into_preds
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:676
0xeeb454 convert_control_dep_chain_into_preds
../../gcc-source-trunk/gcc/vec.h:826
0xeeb454 find_predicates
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:797
0xeeb454 is_use_properly_guarded
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2444
0xeec848 find_uninit_use
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2531
0xeec848 warn_uninitialized_phi
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2601
0xeec848 execute
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


-


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

int a, b, d;
static int c, e, f, g;

int main ()
{ 
  int h = 0, i;
  if (b)
{ 
  d = f;
  if (c)
goto L1;
  goto L2;
}
  for (; h < 2; h++)
{ 
  int l, m = 0;
  for (; e < 2; e++)
{ 
  m = ~m;
L1:;
}
L2:
  while (l)
for (i = 0; i < 2; i++)
  for (g = 0; g < 1; g++)
if (m)
  printf ("%d", a);
}
  return 0;
}

[Bug fortran/82392] Allign arrays for faster execution

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #3 from Wilco  ---
(In reply to Thomas Koenig from comment #2)
> Test case for the fact that we don't align, or that this
> causes a performance loss?

The request is to use a higher alignment than necessary when allocating large
arrays which might result in better performance. I've proposed patches for
malloc to automatically overalign large allocations.

Note small allocations could use alloca rather than malloc even without
-fstack-arrays - this would give Fortran code built with -O2/-O3 a big boost
and avoid the issues caused by -fstack-arrays.

[Bug other/83737] [nvptx] FAIL: gcc.dg/stdint-width-1.c (test for excess errors) for with newlib stdint.h

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
(In reply to jos...@codesourcery.com from comment #4)
> Most configurations (for which the libc used has a working stdint.h) 
> should probably be using use_gcc_stdint=wrap, so that GCC's stdint.h 
> includes libc's for hosted compilations but GCC's own for freestanding 
> compilations.  *-*-elf configurations do, for example.  I'd advise adding 
> that for nvptx. 

I've build nvptx using "use_gcc_stdint=wrap", and indeed that fixed the failure

I'll do full testing and commit.

[Bug libstdc++/80276] pretty printer for std::unique_ptr<T[]> shows type as std::unique_ptr

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
unique_ptr>[]> is shown as:

type = std::unique_ptr*, std::default_delete*> >, std::allocator*, std::default_delete*> > > > []>

[Bug libstdc++/80276] pretty printer for std::unique_ptr<T[]> shows type as std::unique_ptr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
We no longer get an error, but don't apply the type printers everywhere that we
should e.g. std::unique_ptr is printed as:

type = std::unique_ptr []>

And similarly for unique_ptr

[Bug rtl-optimization/80481] Unoptimal additional copy instructions

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Vladimir Makarov  ---
  I've started to work on this.  The problem is not in LRA.  It is driven by
IRA decision which assigns different registers to pseudos should be the same in
fma_fnmadd_v16sf.  This results in generation of the additional move insns.

  IRA is driven by many heuristics which sometimes contradict each other and
for this particular case the result is not good.  I'll try to find what
heuristics are responsible for this.  As heuristics affect the generated code
performance, the fix might take a lot of time because besides patch creation
the fix will need a performance evaluation probably on a few targets.

[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess

[msebor at gcc dot gnu.org]

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

--- Comment #16 from Martin Sebor  ---
The GCC warning detects several distinct kinds of undefined behavior, most of
which cannot very well be made well-defined.  Making changes to the checker
just because a subset of the undefined cases are viewed as less severe than
another, or with the expectation that a future standard might make that subset
well-defined, would increase the risk of missing the more severe ones.

I wouldn't be opposed to moving the Clang -Wdynamic-class-memaccess subset of
the the warning under its own option in GCC and having that one enabled in
-Wextra rather than -Wall, but I don't support removing the warning in its
entirety from -Wall just to accommodate undefined code in legacy versions of a
single library.

The established way of dealing with new warnings in supported versions of
libraries is to fix the libraries (either by actually removing the problem or
by adding suppression mechanisms).  It's understood that unsupported/legacy
versions of software may not compile cleanly with new versions of compilers and
that some new warnings may need to be disabled.

[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess

[ville.voutilainen at gmail dot com]

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

--- Comment #15 from Ville Voutilainen  ---
I would like to have the change be a DR. Anyway, I looked at the cast-less
cases, they are in qtransform.h, which is included by at least QImage and
QtGui, so there will be a fair amount of code that will hit the problem. It's
likely less severe than the casting case, but quite annoying still. This will
also probably cause churn in linux distros when they update their compiler.

I'm not a fan of taking the warning out of -Wall. But I think it's probably the
less painful approach for existing code.

[Bug libstdc++/81584] Pretty Printer for string* doesn't work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Thank for confirming.

[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Guess it is Jason's or Nathan's call.
It also depends if what you're trying to convince the committee is going to be
a DR or just a C++2A change, if the former and it makes it in, sure the warning
should be moved out of -Wall/-Wextra as a style warning or whatever or killed
altogether (unless parts of it will be valid and parts of it invalid).
If it is just a C++2A change, then it perhaps should stay for older code?

[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess

[ville.voutilainen at gmail dot com]

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

--- Comment #13 from Ville Voutilainen  ---
I understand that, but considering that I plan to convince the committee that
the bit-blasts like Qt does should be well-defined, the warning is a bit eager,
cast or no cast. And since it does break existing users, I would prefer having
the warning be an opt-in rather than opt-out.

[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Every GCC release comes with a http://gcc.gnu.org/gcc-7/porting_to.html
(similarly for other releases and we'll have one for gcc-8 too), and especially
with -Werror people need to adjust their codes not just for stuff that is newly
flagged as errors, but also for the warnings.  If we were required not to issue
any new warnings on some set of packages, we could probably never introduce new
warnings at all.

[Bug preprocessor/83773] New: Warning for redefined macro does not have its own -Wsomething switch

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 83773
   Summary: Warning for redefined macro does not have its own
-Wsomething switch
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

Warning for redefined macro does not have its own -Wsomething switch, please
add one. I also tried to use -fdiagnostics-show-option but it did not help.

[code]
#define AAA 1
#define AAA 2
[/code]

[out]
test.c:2: warning: "AAA" redefined
 #define AAA 2

test.c:1: note: this is the location of the previous definition
 #define AAA 1
[/out]

[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess

[ville.voutilainen at gmail dot com]

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

--- Comment #11 from Ville Voutilainen  ---
The issue is again that users of existing Qt versions will see the warnings,
and they also turn to errors. I can fix the non-casting uses, but I would
recommend removing this warning from -Wall as well.

[Bug c++/82541] Wduplicated-branches triggers in template context

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/82541] Wduplicated-branches triggers in template context

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/82541] Wduplicated-branches triggers in template context

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan 10 17:05:14 2018
New Revision: 256441

URL: https://gcc.gnu.org/viewcvs?rev=256441=gcc=rev
Log:
PR c++/82541
* call.c (build_conditional_expr_1): Check complain before warning.
* pt.c (tsubst_copy_and_build) : Suppress
-Wduplicated-branches.

* g++.dg/warn/Wduplicated-branches4.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/warn/Wduplicated-branches4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
How many and how hard would it be to add those casts?
Or use -Wno-class-memaccess in code that can't be fixed easily.

Anyway, the #c0 reported regression is now fixed.

[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 10 16:59:09 2018
New Revision: 256440

URL: https://gcc.gnu.org/viewcvs?rev=256440=gcc=rev
Log:
PR c++/81327
* call.c (maybe_warn_class_memaccess): Add forward declaration.
Change last argument from tree * to const vec *, adjust
args uses and check number of operands too.  Don't strip away any
nops.  Use maybe_constant_value when looking for INTEGER_CST args.
Deal with src argument not having pointer type.  Check
tree_fits_uhwi_p before calling tree_to_uhwi.  Remove useless
test.
(build_over_call): Call maybe_warn_class_memaccess here on the
original arguments.
(build_cxx_call): Rather than here on converted arguments.

* g++.dg/Wclass-memaccess-2.C: Don't expect a warning when explicitly
cast to void *.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/Wclass-memaccess-2.C

[Bug c++/83769] Statement expression inside lambda defined and evaluated in global scope fails to compile with optimizations

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Fixed for GCC 8 via PR 71946.

Note the original bug was reported about inline-asm but the problem was the
same with statement expressions, see comment #6.

[Bug testsuite/83772] ICE in new test case gfortran.fortran-torture/compile/pr83081.f90 in r256423

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-10
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Also seen on x86_64-apple-darwin17.

[Bug c++/71946] asm in toplevel lambda function rejected

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||giel+gcc at mortis dot eu

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

[Bug c++/83769] Statement expression inside lambda defined and evaluated in global scope fails to compile with optimizations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed for GCC 8 via PR 71946.

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

[Bug target/83740] [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140

[gs...@t-online.de]

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

--- Comment #7 from G. Steinmetz  ---
Thanks for working on this issue, Janne. I will check it 
and do some more tests with upcoming snapshot 20180114.

[Bug testsuite/83772] New: ICE in new test case gfortran.fortran-torture/compile/pr83081.f90 in r256423

[seurer at gcc dot gnu.org]

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

Bug ID: 83772
   Summary: ICE in new test case
gfortran.fortran-torture/compile/pr83081.f90 in
r256423
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Given the changelog I wonder if this test case was inadvertently checked in?

This occurs on powerpc64 both be and le.

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran23/../../gfortran
-B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran23/../../
-B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgfortran/
-fno-diagnostics-show-caret -fdiagnostics-color=never -w -O3 -g -c -o
/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/gfortran23/pr83081.o
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr83081.f90
during GIMPLE pass: pcom
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr83081.f90:4:0:
internal compiler error: in probability_in, at profile-count.h:1038
0x10bf8627 profile_count::probability_in(profile_count) const
/home/seurer/gcc/gcc-trunk/gcc/profile-count.h:1038
0x10bf8627 tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
/home/seurer/gcc/gcc-trunk/gcc/tree-ssa-loop-manip.c:1382
0x10b3438f tree_predictive_commoning_loop
/home/seurer/gcc/gcc-trunk/gcc/tree-predcom.c:3279
0x10b3438f tree_predictive_commoning()
/home/seurer/gcc/gcc-trunk/gcc/tree-predcom.c:3312
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
output is:
during GIMPLE pass: pcom
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr83081.f90:4:0:
internal compiler error: in probability_in, at profile-count.h:1038
0x10bf8627 profile_count::probability_in(profile_count) const
/home/seurer/gcc/gcc-trunk/gcc/profile-count.h:1038
0x10bf8627 tree_transform_and_unroll_loop(loop*, unsigned int, edge_def*,
tree_niter_desc*, void (*)(loop*, void*), void*)
/home/seurer/gcc/gcc-trunk/gcc/tree-ssa-loop-manip.c:1382
0x10b3438f tree_predictive_commoning_loop
/home/seurer/gcc/gcc-trunk/gcc/tree-predcom.c:3279
0x10b3438f tree_predictive_commoning()
/home/seurer/gcc/gcc-trunk/gcc/tree-predcom.c:3312