[Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka  ---
I commited the change to mainline, so you only need to update the tree.

Honza

Re: [Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[Jan Hubicka]

I commited the change to mainline, so you only need to update the tree.

Honza

[Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[nheghathivhistha at gmail dot com]

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

--- Comment #6 from David Kredba  ---
Could you please attach the patch as attachement to here? I am not able to save
it as valid patch file even after I switched ml to "raw text".

[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register

[law at redhat dot com]

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

--- Comment #25 from Jeffrey A. Law  ---
Unwanted loads have been eliminated by the postreload-gcse improvements.

[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register

[law at gcc dot gnu.org]

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

--- Comment #24 from Jeffrey A. Law  ---
Author: law
Date: Mon Mar 23 05:21:04 2015
New Revision: 221585

URL: https://gcc.gnu.org/viewcvs?rev=221585&root=gcc&view=rev
Log:
   PR rtl-optimization/64317
* Makefile.in (OBJS): Add gcse-common.c
* gcse.c: Include gcse-common.h
(struct modify_pair_s): Move structure definition to gcse-common.h
(compute_transp): Move function to gcse-common.c.
(canon_list_insert): Similarly.
(record_last_mem_set_info): Break out some code and put it into
gcse-common.c.  Call into the new common code.
(compute_local_properties): Pass additional arguments to
compute_transp.
* postreload-gcse.c: Include gcse-common.h and df.h
(modify_mem_list_set, blocks_with_calls): New variables.
(modify_mem_list, canon_modify_mem_list, transp): Likewise.
(get_bb_avail_insn): Pass in the expression index too.
(alloc_mem): Allocate memory for the new bitmaps and lists.
(free_mem): Free memory for the new bitmaps and lists.
(insert_expr_in_table): Record a bitmap index for each entry we
add to the table.
(record_last_mem_set_info): Call into common code in gcse-common.c.
(get_bb_avail_insn): If no available insn was found in the requested
BB.  If BB has a single predecessor, see if the expression is
transparent in BB and available in that single predecessor.
(compute_expr_transp): New wrapper for compute_transp.
(eliminate_partially_redundant_load): Pass expression's bitmap_index
to get_bb_avail_insn.  Compute next_pred_bb_end a bit later.
(gcse_after_reload_main): If there are elements in the hash table,
then compute transparency for all the elements in the hash table.
* gcse-common.h: New file.
* gcse-common.c: New file.

Added:
trunk/gcc/gcse-common.c
trunk/gcc/gcse-common.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/gcse.c
trunk/gcc/postreload-gcse.c

[Bug c++/52036] C++11 allows template parameters to have internal linkage

[oakad at yahoo dot com]

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

Alexander Dubov  changed:

   What|Removed |Added

 CC||oakad at yahoo dot com

--- Comment #10 from Alexander Dubov  ---
Still an issue on GCC-4.9.2 (-std=c++11, c++14, gnu++1y). clang-3.4 compiles
this and similar cases just fine.

[Bug fortran/62049] Negative count_rate when calling system_clock

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||jvdelisle at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jerry DeLisle  ---
This PR has been fixed.  See PR64432

[Bug fortran/60956] [4.8/4.9/5 Regression] error reading (and writing) large text files in gfortran

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #12 from Jerry DeLisle  ---
Backported and closing.

[Bug ada/65519] Unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE if ZCX_By_Default is set False

[syq at debian dot org]

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

--- Comment #1 from YunQiang Su  ---
It only fails when using -O2 +, while
build successfully when using -O1.

[Bug c++/65520] New: elaborated-type-specifiers and inaccessible injected-class-names

[rs2740 at gmail dot com]

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

Bug ID: 65520
   Summary: elaborated-type-specifiers and inaccessible
injected-class-names
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com

Repro:

struct A {};
struct B : private A {};
struct C : public B {
struct A m_a; // error: A is the inaccessible injected-class-name
};

Per [basic.lookup.elab]/p2, the elaborated-type-specifier `struct A` should
cause an unqualified name lookup for `A`, and per [basic.lookup.unqual]/p7 the
name is first searched in C and its base classes, which should find the
inaccessible injected-class-name, rendering the code ill-formed.

Instead, GCC accepts this code. It is rejected by all versions of Clang I
tested (3.0 and later).

[Bug ada/65519] New: Unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE if ZCX_By_Default is set False

[syq at debian dot org]

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

Bug ID: 65519
   Summary: Unable to coalesce ssa_names 2 and 87 which are marked
as MUST COALESCE if ZCX_By_Default is set False
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syq at debian dot org

Created attachment 35101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35101&action=edit
the required files

/home/syq/gcctest/gcc-5-5-20150321/build/./gcc/xgcc
-B/home/syq/gcctest/gcc-5-5-20150321/build/./gcc/ -B/usr/x86_64-linux-gnu/bin/
-B/usr/x86_64-linux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/include -isystem
/usr/x86_64-linux-gnu/sys-include -isystem
/home/syq/gcctest/gcc-5-5-20150321/build/sys-include-c -g -O2   -W -Wall
-gnatpg -gnata -nostdinc   g-sptavs.ads -o g-sptavs.o

Unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE.
I.3_2(ab) and  I.3_87(ab)
+===GNAT BUG DETECTED==+
| 5.0.0 20150321 (experimental) [trunk revision 221551] (x86_64-linux-gnu) GCC
error:|
| SSA corruption   |
| Error detected around g-spitbo.ads:373:12|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

system.ads
g-sptavs.ads
g-spitbo.ads
gnat.ads
ada.ads
a-finali.ads
s-finroo.ads
a-string.ads
a-strunb.ads
a-strmap.ads
a-charac.ads
a-chlat1.ads
s-atocou.ads
interfac.ads
a-tags.ads
s-stoele.ads
s-stalib.ads
a-unccon.ads
s-exctab.ads
a-stream.ads
s-soflin.ads
a-except.ads
s-parame.ads
s-traent.ads
s-stache.ads
s-unstyp.ads
s-stratt.ads
s-secsta.ads
s-stposu.ads
s-stopoo.ads
s-finmas.ads
s-pooglo.ads
s-ststop.ads
s-string.ads
a-uncdea.ads
g-spitbo.adb
a-stunau.ads
g-debuti.ads
g-io.ads
s-strhas.ads
s-valint.ads
s-strhas.adb
s-stalib.adb
s-memory.ads
s-stoele.adb


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423
../gcc-interface/Makefile:311: recipe for target 'g-sptavs.o' failed


I can reproduce it on mips64el and amd64.

[Bug fortran/60956] [4.8/4.9/5 Regression] error reading (and writing) large text files in gfortran

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Mar 23 01:32:15 2015
New Revision: 221584

URL: https://gcc.gnu.org/viewcvs?rev=221584&root=gcc&view=rev
Log:
2015-03-22  Jerry DeLisle  

PR libgfortran/60956
Backport from mainline
* io/fbuf.c (fbuf_flush_list): New function that only flushes
if current fbuf position exceeds a limit.
* io/fbuf.h: Declare the new function.
* io/io.h (enum unit_mode): Add two new modes.
* io/list_read.c (list_formatted_read_scalar): Call new function.
* io/write.c: Include fbuf.h. (list_formatted_write_scalar):
Call new function.

Modified:
branches/gcc-4_8-branch/libgfortran/ChangeLog
branches/gcc-4_8-branch/libgfortran/io/fbuf.c
branches/gcc-4_8-branch/libgfortran/io/fbuf.h
branches/gcc-4_8-branch/libgfortran/io/io.h
branches/gcc-4_8-branch/libgfortran/io/list_read.c
branches/gcc-4_8-branch/libgfortran/io/write.c

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Created attachment 35100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35100&action=edit
partial patch

Hi,
this is a patch that adds necessary checks into resolution code. Basically if
static linking is anticipated, we can not derive much of useful info from
PREVAILING_DEF/PREVAILING_DEF_IRONLY_EXP and must anticipate that static
linking may change these and drop comdat groups.

THe catch is that someone needs to pass -r to lto1 that is not currently
happening (I verified that if I hack opts.c to set incremental_linking to true
the testcase works).

With -r option, I can imagine that lto-wrapper can do it, because we get:
COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-openmp' '-fno-openacc' '-mtune=generic' '-march=x86-64'
'-O2' '-B' './' '-O2' '-r' '-v' '-mtune=generic' '-march=x86-64'
'-fltrans-output-list=/tmp/cc3o3UIr.ltrans.out' '-fwpa'
'-fresolution=/tmp/cchYXuvF.res

I donot know hwere -r gets dropped though.  But the testcase uses -Wl,-r that
may need LTO plugin extension?

[Bug target/65456] powerpc64le autovectorized copy loop missed optimization

[dje at gcc dot gnu.org]

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

--- Comment #10 from David Edelsohn  ---
I believe that the choice to scalarize is based on the vector cost model.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jan Hubicka  ---
It would help to know the backtrace when stack usage gets out of hand.

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #9 from Jan Hubicka  ---
Fixed.

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Author: hubicka
Date: Mon Mar 23 00:17:07 2015
New Revision: 221582

URL: https://gcc.gnu.org/viewcvs?rev=221582&root=gcc&view=rev
Log:

PR ipa/65475
* ipa-devirt.c: Include demangle.h
(odr_type_d): Add field rtti_broken.
(odr_subtypes_equivalent_p): Do not require name to match.
(compare_virtual_tables): Fix typo; if type already has ODR violation,
bypass the tests; be ready for function referneces in vtables that are
not DECL_VIRTUAL; make warnings to be OPT_Wodr.
(warn_odr): Give up for nameless types.
(warn_types_mismatch): Report mismatch in mangled names;
report mismatch in anonymous namespaces; look into component types to
give useful error; report when mismatch is dragged in from other ODR
type.
(odr_types_equivalent_p): Match types for being polymorphic; avoid
duplicated diagnostics.
(add_type_duplicate): Reorder checks so more informative ones come
first; fix typo; do not output "the extra base is defined here" when
we did not warn.
(BINFO_N_BASE_BINFOS): Relax sanity check.
* g++.dg/lto/pr65475b_0.C: New testcase.
* g++.dg/lto/pr65475b_1.C: New testcase.
* g++.dg/lto/pr65475c_0.C: New testcase.
* g++.dg/lto/pr65475c_1.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr65475b_0.C
trunk/gcc/testsuite/g++.dg/lto/pr65475b_1.C
trunk/gcc/testsuite/g++.dg/lto/pr65475c_0.C
trunk/gcc/testsuite/g++.dg/lto/pr65475c_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/60956] [4.8/4.9/5 Regression] error reading (and writing) large text files in gfortran

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Mar 23 00:16:01 2015
New Revision: 221578

URL: https://gcc.gnu.org/viewcvs?rev=221578&root=gcc&view=rev
Log:
2015-03-22  Jerry DeLisle  

PR libgfortran/60956
Backport from mainline
* io/fbuf.c (fbuf_flush_list): New function that only flushes
if current fbuf position exceeds a limit.
* io/fbuf.h: Declare the new function.
* io/io.h (enum unit_mode): Add two new modes.
* io/list_read.c (list_formatted_read_scalar): Call new function.
* io/write.c: Include fbuf.h. (list_formatted_write_scalar):
Call new function.

Modified:
branches/gcc-4_9-branch/libgfortran/ChangeLog
branches/gcc-4_9-branch/libgfortran/io/fbuf.c
branches/gcc-4_9-branch/libgfortran/io/fbuf.h
branches/gcc-4_9-branch/libgfortran/io/io.h
branches/gcc-4_9-branch/libgfortran/io/list_read.c
branches/gcc-4_9-branch/libgfortran/io/write.c

[Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-03-23
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Jan Hubicka  ---
Hi,
I hope this is fixed by
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01151.html
(I plan to commit that patch today). Can you please check if build works for
you with the patch?  I tried you preprocessed files as follows:
$ /aux/hubicka/trunk-install/bin/g++ -Wall -Wpointer-arith -Woverloaded-virtual
-Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null
-Wsign-compare -Wno-invalid-offsetof -Wcast-align -flto=4 -fuse-linker-plugin
-O2 -g -pipe -march=core2 -mtune=core2 -fno-rtti -ffunction-sections
-fdata-sections -fno-exceptions -pthread -pipe  -DNDEBUG -DTRIMMED 
-fno-omit-frame-pointer  -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 -fPIC
-shared ?.ii -lpthread -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2
-Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2
-Wl,--build-id   -Wl,-rpath-link,./dist/bin -Wl,-rpath-link,/usr/lib   -lplds4
-lplc4 -lnspr4 -lpthread -ldl-ldl  -lm -lz -ldl $ 


and get no ICE.

[Bug target/65505] [5 Regression][SH] ICE in sh_disp_addr_displacement

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #2)
> I'm now testing the patch in attachment 35084 [details] on sh-elf.
> Kaz, could you please also pre-test it on sh4-linux?

No new failures on sh4-unknown-linux-gnu.

[Bug tree-optimization/65518] gcc consumes all memory with -O3

[ikonomisma at googlemail dot com]

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

ikonomisma at googlemail dot com changed:

   What|Removed |Added

  Component|c   |tree-optimization

--- Comment #1 from ikonomisma at googlemail dot com ---
A comment on
http://stackoverflow.com/questions/29200652/gcc-consumes-all-memory-when-optimizing-o3
suggests -ftree-vectorize triggers the condition

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[manu at gcc dot gnu.org]

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

--- Comment #12 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #11)
> Great, then my suggestion would be to use exactly the same wording for
> references.

I guess the Clang devs added their wording because someone mistakenly assumed
(like in Jan's original testcase) that applying & to a reference bounded to *p,
when p is NULL may return false. That said, I find their wording very
confusing.

Also, above you said that "&r is not the address of a reference, it's the
address of whatever the reference is bound to", thus using the same working
seems confusing.

But I trust the person that submits a proper patch to choose whatever wording
they feel appropriate.

[Bug c/65518] New: gcc consumes all memory with -O3

[ikonomisma at googlemail dot com]

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

Bug ID: 65518
   Summary: gcc consumes all memory with -O3
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ikonomisma at googlemail dot com

Attempting to compile the following function at -O3 on (at least) gcc 4.8.2
consumes all available memory:

#include 
#include 

typedef struct giga
{
  uint64_t g[0x1000];
} giga;

uint64_t addfst(giga const *gptr, size_t num)
{
  uint64_t retval = 0;
  for (size_t i = 0; i < num; i++)
{
  retval += gptr[i].g[0];
}
  return retval;
}

[Bug ipa/65502] pure-const should play well with clobbers.

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-22
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Jan Hubicka  ---
The ICE is now solved. Changing to enhancement for ipa-pure-const/Clobber
generation.

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Great, then my suggestion would be to use exactly the same wording for
references.

[Bug libfortran/59513] [4.8/4.9/5 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #30 from Jerry DeLisle  ---
Fixed on 5.0, will backport in a few days.

[Bug libfortran/59513] [4.8/4.9/5 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[jvdelisle at gcc dot gnu.org]

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

--- Comment #29 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Mar 22 21:37:13 2015
New Revision: 221575

URL: https://gcc.gnu.org/viewcvs?rev=221575&root=gcc&view=rev
Log:
2015-03-22 Jerry DeLisle  

PR libgfortran/59513
* gfortran.texi (Read/Write after EOF marker): New information.

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

[Bug ipa/65502] pure-const should play well with clobbers.

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Author: hubicka
Date: Sun Mar 22 21:10:24 2015
New Revision: 221574

URL: https://gcc.gnu.org/viewcvs?rev=221574&root=gcc&view=rev
Log:

PR ipa/65502
* ipa-comdats.c (enqueue_references): Walk through thunks.
(ipa_comdats): Likewise.
(set_comdat_group_1): New function.

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

[Bug middle-end/65517] [5 Regression] ICE: in get_loop_body, at cfgloop.c:856

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Started with r221409.

trippels@gcc2-power8 ~ % ~/gcc_build_dir_/gcc/cc1 -fpreprocessed foo.i -quiet
-dumpbase foo.i -auxbase foo -O2 -w -version -o /dev/null
GNU C11 (GCC) version 5.0.0 20150313 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 4.9.2 20141101 (Red Hat 4.9.2-1), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 5.0.0 20150313 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 4.9.2 20141101 (Red Hat 4.9.2-1), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 2d7bc906d0f6d4e6259d8a0bcfb20c0d
foo.i: In function ‘main’:
foo.i:13:1: error: size of loop 1 should be 1, not 2
 }
 ^
foo.i:13:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1652
0x102e6a4f verify_loop_structure()
../../gcc/gcc/cfgloop.c:1652
0x1061f8e3 loop_optimizer_init(unsigned int)
../../gcc/gcc/loop-init.c:123
0x1094059f perform_tree_ssa_dce
../../gcc/gcc/tree-ssa-dce.c:1637
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions

[Bug c++/65503] g++ string array in struct crash

[maltsevm at gmail dot com]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||maltsevm at gmail dot com

--- Comment #2 from Mikhail Maltsev  ---
Also, I noticed that in some cases GCC is able to generate a loop for
initialization:

#include 

int main() {
std::string m[1000] {"x", "y"};
std::string n[1000] = {"x", "y"};
}

That is done in cp/init.c:build_vec_init. But for the original testcase, the
loop is not created. Is it a bug?

[Bug middle-end/65517] [5 Regression] ICE: in get_loop_body, at cfgloop.c:856

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-22
 CC||trippels at gcc dot gnu.org
  Component|lto |middle-end
Summary|src/getargs.c:112:1:|[5 Regression] ICE: in
   |internal compiler error: in |get_loop_body, at
   |get_loop_body, at   |cfgloop.c:856
   |cfgloop.c:856   |
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Quick reduction:

markus@x4 testc % cat foo.i
typedef (*argmatch_exit_fn)();
a;
__argmatch_die () { exit (0); }

main ()
{
  while (1)
{
  argmatch_exit_fn b = __argmatch_die;
  if (a)
b ();
}
}

markus@x4 testc % gcc -w -O2 foo.i
foo.i: In function ‘main’:
foo.i:13:1: internal compiler error: in get_loop_body, at cfgloop.c:856

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #9)
> > What about "the address of the object bound to 'r' may be assumed to always
> > convert to true"?
> 
> Why only warn about references, and not also for int i; bool b = !&i;  ?

We already do:

/home/manuel/test.c:3:21: warning: the address of ‘i’ will always evaluate as
‘true’ [-Waddress]
   int i; bool b = !&i;
 ^

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Manuel López-Ibáñez from comment #8)
> Sure, I was trying to make the Clang message a bit more understandable. I
> got completely confused by "pointer may be assumed to always convert to
> true" when there is no pointer (in my last testcase).

&r is a pointer.

> What about "the address of the object bound to 'r' may be assumed to always
> convert to true"?

Why only warn about references, and not also for int i; bool b = !&i;  ?

> I'm not sure if we can tell that 'r' is bounded to a dereferenced pointer at
> the point of warning. If so, then it could print "because in C++ a reference
> cannot be bound to a dereferenced null pointer", but this seems less
> important.

That would be worse IMHO.

[Bug rtl-optimization/60851] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
Created attachment 35099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35099&action=edit
Proposed patch for 4.9 branch

In 4.9 branch, the check is located in three different places throughout
constrain_operands. There was a big cleanup by Richard Sandiford in this area
[1].

Richard, does the patch looks OK to you?

[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00530.html

[Bug lto/65517] New: src/getargs.c:112:1: internal compiler error: in get_loop_body, at cfgloop.c:856

[nheghathivhistha at gmail dot com]

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

Bug ID: 65517
   Summary: src/getargs.c:112:1: internal compiler error: in
get_loop_body, at cfgloop.c:856
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nheghathivhistha at gmail dot com

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

Gcc trunk revision 221558 ICEs LTObuild of Bison:

x86_64-pc-linux-gnu-gcc   -flto=4 -fuse-linker-plugin -O2 -g -pipe -march=core2
-mtune=core2  -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2
-Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2
-o src/bison src/bison-AnnotationList.o src/bison-InadequacyList.o
src/bison-LR0.o src/bison-Sbitset.o src/bison-assoc.o src/bison-closure.o
src/bison-complain.o src/bison-conflicts.o src/bison-derives.o
src/bison-files.o src/bison-getargs.o src/bison-gram.o src/bison-graphviz.o
src/bison-lalr.o src/bison-ielr.o src/bison-location.o src/bison-main.o
src/bison-muscle-tab.o src/bison-named-ref.o src/bison-nullable.o
src/bison-output.o src/bison-parse-gram.o src/bison-print-xml.o
src/bison-print.o src/bison-print_graph.o src/bison-reader.o src/bison-reduce.o
src/bison-relation.o src/bison-scan-code-c.o src/bison-scan-gram-c.o
src/bison-scan-skel-c.o src/bison-state.o src/bison-symlist.o
src/bison-symtab.o src/bison-tables.o src/bison-uniqstr.o lib/libbison.a  
src/getargs.c: In function 'flags_argmatch.part.0.constprop':
src/getargs.c:112:1: internal compiler error: in get_loop_body, at
cfgloop.c:856
 flags_argmatch (const char *option,
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: ***
[/var/tmp/portage/sys-devel/bison-3.0.4/temp/ccD6YKNn.ltrans10.ltrans.o] Error
1
make[3]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.10.0-pre20150320/../../../../x86_64-pc-linux-gnu/bin/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status

gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.10.0-pre20150320/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.10.0-pre20150320/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.10.0_pre20150320/work/gcc-4.10.0-20150320/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.10.0-pre20150320
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.10.0-pre20150320/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-pre20150320
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-pre20150320/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-pre20150320/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.10.0-pre20150320/include/g++-v4
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-pre20150320/python
--enable-languages=c,c++,fortran,ada --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.10.0_pre20150320' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --enable-lto
--with-cloog --disable-isl-version-check --enable-libsanitizer
Thread model: posix
gcc version 4.10.0-pre20150320 20150321 (experimental) [trunk revision 221558]
(Gentoo 4.10.0_pre20150320)

[Bug rtl-optimization/60851] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||rsandifo at gcc dot gnu.org
   Assignee|ubizjak at gmail dot com   |unassigned at gcc dot 
gnu.org
Summary|[4.9/5 Regression] ICE: in  |[4.9 Regression] ICE: in
   |extract_constrain_insn_cach |extract_constrain_insn_cach
   |ed, at recog.c:2117 with|ed, at recog.c:2117 with
   |-flive-range-shrinkage  |-flive-range-shrinkage
   |-mdispatch-scheduler|-mdispatch-scheduler
   |-march=bdver4   |-march=bdver4
  Known to fail|5.0 |

--- Comment #12 from Uroš Bizjak  ---
On the 4.9 branch, the patched compiler still results in the ICE. It looks like
branch and mainline are substantially different in recog.c infrastructure, and
proposed simple patch is ineffective on the branch.

Unassigning, a recog infrastructure expert (CC'd) is needed here.

[Bug libfortran/59513] [4.8/4.9/5 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

[jvdelisle at gcc dot gnu.org]

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

--- Comment #28 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Mar 22 18:42:52 2015
New Revision: 221572

URL: https://gcc.gnu.org/viewcvs?rev=221572&root=gcc&view=rev
Log:
2015-03-22 Jerry DeLisle  

PR libgfortran/59513
* io/transfer.c (data_transfer_init): Do not error for
-std=legacy.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #7)
> The diagnostic needs rewording, &r is not the address of a reference, it's
> the address of whatever the reference is bound to. Please don't add
> diagnostics that talk about something that has no meaning in the language.
> 
> It's not really relevant that r is a reference, &r takes the address of an
> object, so must be non-zero because you can't have an object with address
> zero.

Sure, I was trying to make the Clang message a bit more understandable. I got
completely confused by "pointer may be assumed to always convert to true" when
there is no pointer (in my last testcase).

What about "the address of the object bound to 'r' may be assumed to always
convert to true"?

I'm not sure if we can tell that 'r' is bounded to a dereferenced pointer at
the point of warning. If so, then it could print "because in C++ a reference
cannot be bound to a dereferenced null pointer", but this seems less important.

In any case, I just wanted to demonstrate that there is no "technical"
impediment to implement such a diagnostic in GCC. In fact, it is quite trivial.
That is, Clang does not have this warning because of some magic sauce in its
code, but simply because, for some reason, they have succeeded in attracting
developers who have the time to implement such things.

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The diagnostic needs rewording, &r is not the address of a reference, it's the
address of whatever the reference is bound to. Please don't add diagnostics
that talk about something that has no meaning in the language.

It's not really relevant that r is a reference, &r takes the address of an
object, so must be non-zero because you can't have an object with address zero.

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||patch
 CC||polacek at redhat dot com

--- Comment #6 from Manuel López-Ibáñez  ---
I'm too busy to even test this properly. Perhaps it needs some tweaks to not
warn in some cases. Please, Mareck, Paolo or Jason, feel free to take it.

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[jan.kratochvil at redhat dot com]

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

--- Comment #5 from Jan Kratochvil  ---
(In reply to Manuel López-Ibáñez from comment #3)
> Does this patch work in your real-world code?

There were just many tests like:
  if (!&r)
return 0;
So it should really work, thanks.

[Bug rtl-optimization/65504] [4.9/5 Regression] select case with strings and -fgcse -O

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
It's a bug in Dead Store Elimination (so -fno-dse is the workaround) exposed by
a combination of GCSE and FWPROP which changes the canonicalization of
addresses (so -fno-gcse and -fno-forward-propagate paper over the bug).

[Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[nheghathivhistha at gmail dot com]

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

--- Comment #4 from David Kredba  ---
Created attachment 35097
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35097&action=edit
Preprocessed source file gzipped

[Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[nheghathivhistha at gmail dot com]

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

--- Comment #3 from David Kredba  ---
Created attachment 35096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35096&action=edit
Preprocessed source file gzipped

[Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[nheghathivhistha at gmail dot com]

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

--- Comment #2 from David Kredba  ---
Created attachment 35095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35095&action=edit
Preprocessed source file gzipped

[Bug ipa/65516] lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[nheghathivhistha at gmail dot com]

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

--- Comment #1 from David Kredba  ---
Created attachment 35094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35094&action=edit
Preprocessed source file gzipped

[Bug ipa/65516] New: lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:1809

[nheghathivhistha at gmail dot com]

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

Bug ID: 65516
   Summary: lto1: internal compiler error: in get_odr_type, at
ipa-devirt.c:1809
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nheghathivhistha at gmail dot com

Spidermonkey compilation ICEs lto1, trunk revision 221558.

/var/tmp/portage/dev-lang/spidermonkey-24.2.0-r2/work/mozjs-24.2.0/js/src/_virtualenv/bin/python
./config/expandlibs_exec.py --depend .deps/.//libmozjs-24.so.pp --target
libmozjs-24.so --uselist --  x86_64-pc-linux-gnu-g++  -Wall -Wpointer-arith
-Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body
-Werror=conversion-null -Wsign-compare -Wno-invalid-offsetof -Wcast-align
-flto=4 -fuse-linker-plugin -O2 -g -pipe -march=core2 -mtune=core2 -fno-rtti
-ffunction-sections -fdata-sections -fno-exceptions -pthread -pipe  -DNDEBUG
-DTRIMMED  -fno-omit-frame-pointer  -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1
-fPIC -shared -Wl,-z,defs -Wl,-h,libmozjs-24.so -o libmozjs-24.so 
bignum-dtoa.o bignum.o cached-powers.o diy-fp.o double-conversion.o fast-dtoa.o
fixed-dtoa.o strtod.o HashFunctions.o Poison.o SHA1.o Decimal.o
ArgumentsObject.o BytecodeCompiler.o BytecodeEmitter.o CharacterEncoding.o
DateTime.o Debugger.o Eval.o ExecutableAllocator.o FoldConstants.o ForkJoin.o
GlobalObject.o Interpreter.o Intl.o Iteration.o LifoAlloc.o MapObject.o
Marking.o Memory.o Module.o Monitor.o NameFunctions.o Nursery.o Object.o
ObjectImpl.o PageBlock.o ParallelArray.o ParseMaps.o ParseNode.o Parser.o
Probes.o Profilers.o PropertyKey.o RegExp.o RegExpObject.o RegExpStatics.o
RootMarking.o SPSProfiler.o ScopeObject.o SelfHosting.o Shape.o Stack.o
Statistics.o StoreBuffer.o String.o StringBuffer.o TestingFunctions.o
ThreadPool.o TokenStream.o Unicode.o Verifier.o Xdr.o YarrCanonicalizeUCS2.o
YarrInterpreter.o YarrPattern.o YarrSyntaxChecker.o Zone.o jsalloc.o
jsanalyze.o jsapi.o jsarray.o jsatom.o jsbool.o jsclone.o jscntxt.o
jscompartment.o jscrashreport.o jsdate.o jsdbgapi.o jsdtoa.o jsexn.o
jsfriendapi.o jsfun.o jsgc.o jsinfer.o jsiter.o jsmath.o jsmemorymetrics.o
jsnativestack.o jsnum.o jsobj.o json.o jsonparser.o jsopcode.o jsperf.o jsprf.o
jspropertytree.o jsproxy.o jsreflect.o jsscript.o jsstr.o jstypedarray.o
jsutil.o jswatchpoint.o jsweakmap.o jsworkers.o jswrapper.o prmjtime.o
sharkctl.o ExecutableAllocatorPosix.o OSAllocatorPosix.o pm_linux.o   
-lpthread -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2
-Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2
-Wl,--build-id   -Wl,-rpath-link,./dist/bin -Wl,-rpath-link,/usr/lib   -lplds4
-lplc4 -lnspr4 -lpthread -ldl -Wl,-version-script,symverscript -licui18n
-licuuc -licudata   -ldl  -lm -lz -ldl  
Executing: x86_64-pc-linux-gnu-g++ -Wall -Wpointer-arith -Woverloaded-virtual
-Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null
-Wsign-compare -Wno-invalid-offsetof -Wcast-align -flto=4 -fuse-linker-plugin
-O2 -g -pipe -march=core2 -mtune=core2 -fno-rtti -ffunction-sections
-fdata-sections -fno-exceptions -pthread -pipe -DNDEBUG -DTRIMMED
-fno-omit-frame-pointer -DUSE_SYSTEM_MALLOC=1 -DENABLE_ASSEMBLER=1 -fPIC
-shared -Wl,-z,defs -Wl,-h,libmozjs-24.so -o libmozjs-24.so
/var/tmp/portage/dev-lang/spidermonkey-24.2.0-r2/work/mozjs-24.2.0/js/src/tmpA0RSz7.list
-lpthread -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2
-Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2
-Wl,--build-id -Wl,-rpath-link,./dist/bin -Wl,-rpath-link,/usr/lib -lplds4
-lplc4 -lnspr4 -lpthread -ldl -Wl,-version-script,symverscript -licui18n
-licuuc -licudata -ldl -lm -lz -ldl
/var/tmp/portage/dev-lang/spidermonkey-24.2.0-r2/work/mozjs-24.2.0/js/src/tmpA0RSz7.list:
INPUT("bignum-dtoa.o")
INPUT("bignum.o")
INPUT("cached-powers.o")
INPUT("diy-fp.o")
INPUT("double-conversion.o")
INPUT("fast-dtoa.o")
INPUT("fixed-dtoa.o")
INPUT("strtod.o")
INPUT("HashFunctions.o")
INPUT("Poison.o")
INPUT("SHA1.o")
INPUT("Decimal.o")
INPUT("ArgumentsObject.o")
INPUT("BytecodeCompiler.o")
INPUT("BytecodeEmitter.o")
INPUT("CharacterEncoding.o")
INPUT("DateTime.o")
INPUT("Debugger.o")
INPUT("Eval.o")
INPUT("ExecutableAllocator.o")
INPUT("FoldConstants.o")
INPUT("ForkJoin.o")
INPUT("GlobalObject.o")
INPUT("Interpreter.o")
INPUT("Intl.o")
INPUT("Iteration.o")
INPUT("LifoAlloc.o")
INPUT("MapObject.o")
INPUT("Marking.o")
INPUT("Memory.o")
INPUT("Module.o")
INPUT("Monitor.o")
INPUT("NameFunctions.o")
INPUT("Nursery.o")
INPUT("Object.o")
INPUT("ObjectImpl.o")
INPUT("PageBlock.o")
INPUT("ParallelArray.o")
INPUT("ParseMaps.o")
INPUT("ParseNode.o")
INPUT("Parser.o")
INPUT("Probes.o")
INPUT("Pr

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
Or even:

int fii(int p) {
  int &r=p;
  return !&r;
}

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
I got confused by Clang's message. The problem is not the pointer or NULL. The
problem is converting the address of a reference to bool:


int fii(int *p) {
  int &r=*p;
  return !&r;
}

This is trivial to implement in GCC:

manuel@gcc14:~$ ~/test1/221557M/build/gcc/cc1plus -Waddress ~/pr65168.cc
/home/manuel/pr65168.cc:3:12: warning: address of reference ‘r’ may be assumed
to always convert to true because in C++ a reference cannot be bound to
dereferenced null pointer [-Waddress]
   return !&r;
^

Does this patch work in your real-world code?

Index: c-common.c
===
--- c-common.c  (revision 221557)
+++ c-common.c  (working copy)
@@ -4776,11 +4776,18 @@ c_common_truthvalue_conversion (location
}

 CASE_CONVERT:
   {
tree totype = TREE_TYPE (expr);
-   tree fromtype = TREE_TYPE (TREE_OPERAND (expr, 0));
+   tree op0 = TREE_OPERAND (expr, 0);
+   tree fromtype = TREE_TYPE (op0);
+
+   if (TREE_CODE (fromtype) == REFERENCE_TYPE
+   && POINTER_TYPE_P (totype) && DECL_P (op0))
+ warning_at (location, OPT_Waddress,
+ "address of reference %qD may be assumed to always
convert to true"
+ " because in C++ a reference cannot be bound to
dereferenced null pointer", op0);

/* Don't cancel the effect of a CONVERT_EXPR from a REFERENCE_TYPE,
   since that affects how `default_conversion' will behave.  */
if (TREE_CODE (totype) == REFERENCE_TYPE
|| TREE_CODE (fromtype) == REFERENCE_TYPE)

[Bug target/65456] powerpc64le autovectorized copy loop missed optimization

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #9 from Bill Schmidt  ---
So, this can be viewed either as a phase-ordering problem or an expand problem;
probably the latter is more correct.

The swap optimization runs early in the RTL phases, shortly after expand.  At
the time that it sees this computation, the RTL represents something more like
this:

lxvd2x 0,9,4
xxpermdi 12,0,0,2
[r18=high half of vs12]
[r19=low half of vs12]
std 18,0,28
std 19,8,28

(This is well before RA so I am making up register numbers for illustration
purposes.)  The swap optimization doesn't know what to do when a vector is
split into pieces, so it punts here.

Later, in the split2 phase that runs after RA, the last four lines above are
recognized as a pattern that can be replaced by an stxvd2x in BE mode, or by an
xxswapd/stxvd2x in LE mode.  This is how we end up with the code you see in the
final output.

The question is, why is the expander generating the two doubleword stores? 
Probably because it thinks that we are ok generating unaligned doubleword
stores, but not ok generating unaligned quadword stores.  In other words, there
is probably something in there that needs to be taught that unaligned vector
stores on P8 are better to use than moving pieces into GPRs and storing them
separately.

I will take on the investigation of this, but there are a few more urgent
things that need attention first.  I expect this to be a fairly easy fix that
we'll be able to backport.

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11   |hppa64-hp-hpux11.11
   Host|hppa2.0w-hp-hpux11.11   |hppa64-hp-hpux11.11
  Build|hppa2.0w-hp-hpux11.11   |hppa64-hp-hpux11.11

--- Comment #1 from John David Anglin  ---
Wrong target and point of introduction.  R212961 was okay and r213683 had
the fail.

[Bug c++/65512] Inconsistent report of uninitialized members

[developm...@faf-ltd.com]

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

--- Comment #5 from Peter VARGA  ---
1) There are bugs which are not important. It is always a point of view. As a
starter here I had 2 possibilities and I took the wrong. More or less you may
be right but it was a simple misunderstanding. AND I did NOT think the bug is
important because I have already a solution. It was blocker for me because
compiler could not finish.

2) :-) - I am used my sources do compile on a very high restrict level. 

3) What about 4.9.3 - is it fixed or not?

[Bug c++/65512] Inconsistent report of uninitialized members

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Peter VARGA from comment #3)
> 1) I had no idea how the importance is qualified. Is my 1st bug report. For
> me it was a blocker because I could not finish compiling

That applies to most bugs if you think about it. And every bug reporter thinks
their bug is important ... to them.

> 2) Not using -Werror is really a bit hard - don't you think?!

Umm, no.

[Bug c++/65512] Inconsistent report of uninitialized members

[developm...@faf-ltd.com]

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

--- Comment #3 from Peter VARGA  ---
1) I had no idea how the importance is qualified. Is my 1st bug report. For me
it was a blocker because I could not finish compiling
2) Not using -Werror is really a bit hard - don't you think?! My workaround is
using the -Wno-missing-field-initializers switch
3) What about 4.9.3 - I cannot use 5.0 once released.

[Bug c++/65512] Inconsistent report of uninitialized members

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|blocker |normal

--- Comment #2 from Jonathan Wakely  ---
This is clearly not severity=blocker. That would mean it should block a
release, which is nonsense as it is already present in existing releases. Just
don't use -Werror if you don't want the error.

There's no warning with 5.0 anyway.

[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||nilschrbrause at googlemail 
dot co
   ||m

--- Comment #8 from Jonathan Wakely  ---
*** Bug 65514 has been marked as a duplicate of this bug. ***

[Bug c++/65514] Initializing a non-static const data member of a template class from a static const data member of another template class results in errors in certain situations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
Sorry, meant to mark as DUPLICATE not FIXED

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

[Bug c++/65514] Initializing a non-static const data member of a template class from a static const data member of another template class results in errors in certain situations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
dup

[Bug c++/65503] g++ string array in struct crash

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
You're creating a huge object on the stack, which is a bad idea, and the
problem is probably that GCC is running out of memory.

[Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context

[ldionne.2 at gmail dot com]

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

--- Comment #5 from Louis Dionne  ---
[Just a quick comment: thank you for being so responsive. Most of my bug
reports on Clang are left hanging for a long while before anyone ever considers
them, and I appreciate it not being the case here.]

[Bug libstdc++/65500] [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-22
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

[Bug lto/65515] New: [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[danglin at gcc dot gnu.org]

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

Bug ID: 65515
   Summary: [5 Regression] FAIL:
gcc.c-torture/compile/limits-fndefn.c   -O2 -flto
-flto-partition=none  (ICE) -- SIGSEGV for stack
growth failure
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-fno-diagnostics
-show-caret -fdiagnostics-color=never -O2 -flto -flto-partition=none -w -c -o
li
mits-fndefn.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/limits-fndef
n.c
^MPid 26539 received a SIGSEGV for stack growth failure.^MPossible causes:
insufficient memory or swap space,^Mor stack size exceeded maxssiz. ^M
xgcc: internal compiler error: Segmentation fault (program cc1)Please submit a
full bug report,with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
^M
Pid 26539 received a SIGSEGV for stack growth failure.^M
Possible causes: insufficient memory or swap space,^M
or stack size exceeded maxssiz. ^M
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gcc.c-torture/compile/limits-fndefn.c   -O2 -flto -flto-partition=none 
(internal compiler error)
FAIL: gcc.c-torture/compile/limits-fndefn.c   -O2 -flto -flto-partition=none 
(test for excess errors)
Excess errors:
Pid 26539 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz. 
xgcc: internal compiler error: Segmentation fault (program cc1)

Similar fails:
FAIL: gcc.c-torture/compile/limits-fndefn.c   -O2 -flto  (internal compiler
error)
FAIL: gcc.c-torture/compile/limits-fndefn.c   -O2 -flto  (test for excess
errors)

This is with 16 MB stack:
# ulimit -s   
16384

On hppa-linux, I've had to use a 32 MB stack to keep some tests from failing.

I marked this as a regression since r221487 and before didn't fail.

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[jan.kratochvil at redhat dot com]

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

--- Comment #2 from Jan Kratochvil  ---
It should check the '!&r' condition which makes no sense.  The variable
initialization in real world programs is too complicated to be able to figure
out it may be NULL.

[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).

[gang.chen.5i5j at gmail dot com]

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

--- Comment #2 from Chen Gang  ---
For test.i:

int oxu_driver_init(void)
{
 *(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
}

If test.i use a valid number (>= 0x10) or normal variable instead of "-1", it
will be OK (the insns are almost the same between using valid numbers and using
variable).

If test.i use 0 (NULL) instead of "-1", it will be OK, too, but it will
generate an abort() insn for it (unlike valid numbers' and variable's insn).

If test.i se invalid number (e.g. -2, -1, 0x1, 0x2 ... 0xf), it will generate a
different insn which can not be recognized by MD file.


So for me, we need process the left invalid numbers just as processing 0 (NULL)
-- generate an abort() insn for them.

[Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
The first snippet in comment 3 started ICEing with r217664.

[Bug c++/65513] gcc stops with "internal compiler error"

[maltsevm at gmail dot com]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||maltsevm at gmail dot com

--- Comment #2 from Mikhail Maltsev  ---
Reproduced on current commit in branch 4.9, fixed on trunk.

What is interesting about this bug, is that when I reduced it, I got a testcase
identical to PR65154 (which also gives ICE on 5.0). So, here is a testcase
reduced in such way, that it's behavior differs (ICE on 4.9, OK for 5.0):

namespace std {
template  struct atomic {
  atomic() = default;
  atomic(_Tp);
};
}
class {
public:
  std::atomic bReadyToFlush;
}

LogThreadsleLogEntries[10]{};

[Bug c++/65514] New: Initializing a non-static const data member of a template class from a static const data member of another template class results in errors in certain situations

[nilschrbrause at googlemail dot com]

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

Bug ID: 65514
   Summary: Initializing a non-static const data member of a
template class from a static const data member of
another template class results in errors in certain
situations
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nilschrbrause at googlemail dot com

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

% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-4.9-20150304/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 20150304 (prerelease) (GCC)

% g++ -std=c++11 test.cpp
test.cpp:12:25: error: expected ‘;’ at end of member declaration
   const int is = add<1, x>::is;
 ^
test.cpp:12:25: error: declaration of ‘const int add1::x’
test.cpp:8:11: error:  shadows template parm ‘int x’
 template  
   ^
test.cpp:12:26: error: expected unqualified-id before ‘>’ token
   const int is = add<1, x>::is;
  ^
test.cpp:12:22: error: wrong number of template arguments (1, should be 2)
   const int is = add<1, x>::is;
  ^
test.cpp:2:7: error: provided for ‘template class add’
 class add 
   ^

Source code is attached.

The error vanishes, when:
- a 'static' is added: const static int is = add<1, x>::is;
- the '1' and the 'x' are reversed: const int is = add::is;
- the RHS is enclosed in paranthesis: const int is = (add<1, x>::is);

[Bug c++/65513] gcc stops with "internal compiler error"

[developm...@faf-ltd.com]

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

--- Comment #1 from Peter VARGA  ---
One of these following steps do not produce any error message and the compiler
can finish successfully:
1) Add {} to the sDateTime member
2) Remove the std::atomic member

[Bug c++/65513] New: gcc stops with "internal compiler error"

[developm...@faf-ltd.com]

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

Bug ID: 65513
   Summary: gcc stops with "internal compiler error"
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: developm...@faf-ltd.com

#include 

class LogEntries
{
public:
charsDateTime [20];
std::atomic   bReadyToFlush;
};

class LogThreads
{
public:
static LogEntries   leLogEntries [10];
};

LogEntries LogThreads::leLogEntries [10] {};

Compiler options:
g++ -v -save-temps -std=c++11 gcc-warning-bug-2.cpp -Wall -Wextra -c -Werror
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations

Output:
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2_source/configure --disable-multilib
Thread model: posix
gcc version 4.9.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra' '-c'
'-Werror' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -E -quiet -v
-D_GNU_SOURCE gcc-warning-bug-2.cpp -mtune=generic -march=x86-64 -std=c++11
-Wall -Wextra -Werror -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -fpch-preprocess -o gcc-warning-bug-2.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/backward
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra' '-c'
'-Werror' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -fpreprocessed
gcc-warning-bug-2.ii -quiet -dumpbase gcc-warning-bug-2.cpp -mtune=generic
-march=x86-64 -auxbase gcc-warning-bug-2 -Wall -Wextra -Werror -std=c++11
-version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o
gcc-warning-bug-2.s
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.2.3, MPFR version 3.1.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.2.3, MPFR version 3.1.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 660c5687a086ea3686f43ea5e642dd2c
gcc-warning-bug-2.cpp:16:43: error: missing initializer for member
‘LogEntries::sDateTime’ [-Werror=missing-field-initializers]
 LogEntries LogThreads::leLogEntries [10] {};
   ^
gcc-warning-bug-2.cpp:16:43: error: missing initializer for member
‘LogEntries::bReadyToFlush’ [-Werror=missing-field-initializers]
gcc-warning-bug-2.cpp: In function ‘void
__static_initialization_and_destruction_0(int, int)’:
gcc-warning-bug-2.cpp:16:43: internal compiler error: in
gimplify_init_constructor, at gimplify.c:4007
0x7f7bc3 gimplify_init_constructor
../../gcc-4.9.2_source/gcc/gimplify.c:4007
0x7f879e gimplify_modify_expr_rhs
../../gcc-4.9.2_source/gcc/gimplify.c:4167
0x7f8874 gimplify_modify_expr
../../gcc-4.9.2_source/gcc/gimplify.c:4486
0x7fab57 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.2_source/gcc/gimplify.c:7627
0x7fc576 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-4.9.2_source/gcc/gimplify.c:5373
0x7fa40d gimplify_cleanup_point_expr
../../gcc-4.9.2_source/gcc/gimplify.c:5149
0x7fa40d gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.2_source/gcc/gimplify.c:7990
0x7fc576 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-4.9.2_source/gcc/gimplify.c:5373
0x7fb023 gimplify_statement_list
../../gcc-4.9.2_source/gcc/gimplify.c:1432
0x7fb023 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-4.9.2_source/gcc/gimplify.c:8042
0x7fc576 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-4.9.2_source/gcc/gimplify.c:5373
0x7fb023 gimplify_statement_list
  

[Bug c++/65512] Inconsistent report of uninitialized members

[developm...@faf-ltd.com]

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

--- Comment #1 from Peter VARGA  ---
Output for the -v option:

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2_source/configure --disable-multilib
Thread model: posix
gcc version 4.9.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra' '-c'
'-Werror' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -E -quiet -v
-D_GNU_SOURCE gcc-warning-bug.cpp -mtune=generic -march=x86-64 -std=c++11 -Wall
-Wextra -Werror -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
-fpch-preprocess -o gcc-warning-bug.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/x86_64-unknown-linux-gnu

/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/backward
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra' '-c'
'-Werror' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/cc1plus -fpreprocessed
gcc-warning-bug.ii -quiet -dumpbase gcc-warning-bug.cpp -mtune=generic
-march=x86-64 -auxbase gcc-warning-bug -Wall -Wextra -Werror -std=c++11
-version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o
gcc-warning-bug.s
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.2.3, MPFR version 3.1.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.9.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 4.2.3, MPFR version 3.1.2,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 660c5687a086ea3686f43ea5e642dd2c

[Bug c++/65512] New: Inconsistent report of uninitialized members

[developm...@faf-ltd.com]

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

Bug ID: 65512
   Summary: Inconsistent report of uninitialized members
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: developm...@faf-ltd.com

#include 

typedef struct
{
charsDateTime [20];
std::atomicbReadyToFlush;
} LogEntries;

typedef struct
{
LogEntriesleLogEntries [1] {};
} LogThreads;

Compiling with g++ -std=c++11 gcc-warning-bug.cpp -Wall -Wextra -Werror
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -c

Compiler error:
gcc-warning-bug.cpp:11:34: error: missing initializer for member
‘LogEntries::sDateTime’ [-Werror=missing-field-initializers]
  LogEntriesleLogEntries [1] {};
  ^
gcc-warning-bug.cpp:11:34: error: missing initializer for member
‘LogEntries::bReadyToFlush’ [-Werror=missing-field-initializers]
cc1plus: all warnings being treated as error


I consider it as a bug because one of these following steps does not produce
the error message:
1) comment the line std::atomicbReadyToFlush;
2) Add {} to char sDateTime [20];

[Bug c++/65509] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started I think with r218462.

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Target|x86_64-linux-gnu|
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-22
 CC||jason at redhat dot com,
   ||manu at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
The return value is optimized to 0 even before reaching GIMPLE, so this can
definitely be warned by the C++ FE.

[Bug c++/65509] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-22
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/65511] transform_to_exit_first_loop looses edge probabilities

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
testcase:
...
#define N 1000

unsigned int a[N];
unsigned int b[N];
unsigned int c[N];

void __attribute__((noclone,noinline))
f (unsigned int n)
{
  int i;

#pragma omp parallel
  {
#pragma omp for
for (i = 0; i < n; ++i)
  c[i] = a[i] + b[i];
  }
}
...

compiled with -O2 -ftree-parallelize-loops=2

[Bug tree-optimization/65511] transform_to_exit_first_loop looses edge probabilities

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
using tentative patch, we get:
...
  if (ivtmp_25 < _12)
goto ;
  else
goto ;
;;succ:   13 [99.0%]  (TRUE_VALUE,EXECUTABLE)
;;14 [1.0%]  (FALSE_VALUE,EXECUTABLE)
...

[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #35078|0   |1
is obsolete||

--- Comment #10 from vries at gcc dot gnu.org ---
Created attachment 35092
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35092&action=edit
WIP patch

Updated patch which fixes probability/frequency. The generated code for the
loopfn is now identical at the optimized dump (previously we were sinking loads
into the loop nest due to the broken probability/frequency). 

The main difference in generated code at the optimized dump is this:
...
   :
+  n_24 = n_5(D);
   .paral_data_store.6.a = &a;
   .paral_data_store.6.b = &b;
   .paral_data_store.6.c = &c;
-  .paral_data_store.6.D.1854 = _12;
+  .paral_data_store.6.D.1854 = n_5(D);
   __builtin_GOMP_parallel (f._loopfn.0, &.paral_data_store.6, 2, 0);
-  ivtmp_27 = (signed int) _12;
-  _29 = a[ivtmp_27];
-  _30 = b[ivtmp_27];
-  _31 = _29 + _30;
-  c[ivtmp_27] = _31;
...

That is, we up the number of iterations with one (from _n - 1 to n), and remove
the peeled-off last loop iteration (the code after the
__builtin_GOMP_parallel).

[Bug tree-optimization/65511] transform_to_exit_first_loop looses edge probabilities

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
tentative patch:
...
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index 0f5e428..837dbbd 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -6175,6 +6175,7 @@ gimple_duplicate_sese_tail (edge entry ATTRIBUTE_UNUSED,
edge exit ATTRIBUTE_UNU
   gphi *phi;
   tree def;
   struct loop *target, *aloop, *cloop;
+  int exit_prob = exit->probability;

   gcc_assert (EDGE_COUNT (exit->src->succs) == 2);
   exits[0] = exit;
@@ -6266,6 +6267,8 @@ gimple_duplicate_sese_tail (edge entry ATTRIBUTE_UNUSED,
edge exit ATTRIBUTE_UNU
   sorig = single_succ_edge (switch_bb);
   sorig->flags = exits[1]->flags;
   snew = make_edge (switch_bb, nentry_bb, exits[0]->flags);
+  snew->probability = exit_prob;
+  sorig->probability = REG_BR_PROB_BASE - exit_prob;

   /* Register the new edge from SWITCH_BB in loop exit lists.  */
   rescan_loop_exit (snew, true, false);
...

[Bug c++/65509] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
I agree that this code should be accepted. Interestingly, the compiler accepts
the code when the constexpr specifier of both i1 and i2 is removed.

[Bug tree-optimization/65511] New: transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

Bug ID: 65511
   Summary: transform_to_exit_first_loop
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

before transform_to_exit_first_loop the loop backedge/exit edge probabilities
are 99/1:
...
  if (i.0_21 < n_5(D))
goto ;
  else
goto ;
;;succ:   9 [99.0%]  (TRUE_VALUE,EXECUTABLE)
;;6 [1.0%]  (FALSE_VALUE,EXECUTABLE)
...

afterwards, they are 100/0:
...
  # ivtmp_25 = PHI <0(11), ivtmp_23(7)>
  if (ivtmp_25 < _12)
goto ;
  else
goto ;
;;succ:   13 [100.0%]  (TRUE_VALUE,EXECUTABLE)
;;14 (FALSE_VALUE,EXECUTABLE)
...

[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).

[gang.chen.5i5j at gmail dot com]

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

Chen Gang  changed:

   What|Removed |Added

 CC||gang.chen.5i5j at gmail dot com

--- Comment #1 from Chen Gang  ---
I shall try to fix it within this month (2015-03-31).

[Bug target/65510] New: target-tic6x: unrecognizable insn with -O(1,2,3,s).

[gang.chen.5i5j at gmail dot com]

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

Bug ID: 65510
   Summary: target-tic6x: unrecognizable insn with -O(1,2,3,s).
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gang.chen.5i5j at gmail dot com

[root@localhost c6x]# cat test.i 
int oxu_driver_init(void)
{
 *(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
}

[root@localhost c6x]#
/upstream/release-c6x/libexec/gcc/tic6x-gchen-elf/5.0.0/cc1 -Os test.i
 oxu_driver_init
test.i: In function 'oxu_driver_init':
test.i:4:1: error: unrecognizable insn:
 }
 ^
(insn 9 8 12 2 (set (mem/v:SI (reg/f:SI 77) [1 MEM[(volatile unsigned int
*)4294967295B]+0 S4 A8])
(unspec:SI [
(reg:SI 73 [ D.1542 ])
] UNSPEC_MISALIGNED_ACCESS)) test.i:3 -1
 (nil))
test.i:4:1: internal compiler error: in extract_insn, at recog.c:2343
0x9f8645 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-c6x/gcc/rtl-error.c:110
0x9f8679 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-c6x/gcc/rtl-error.c:118
0x9ce127 extract_insn(rtx_insn*)
../../gcc-c6x/gcc/recog.c:2343
0x7c759b instantiate_virtual_regs_in_insn
../../gcc-c6x/gcc/function.c:1598
0x7c759b instantiate_virtual_regs
../../gcc-c6x/gcc/function.c:1966
0x7c759b execute
../../gcc-c6x/gcc/function.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[root@localhost c6x]# 

[root@localhost c6x]# /upstream/release-c6x/bin/tic6x-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release-c6x/bin/tic6x-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/upstream/release-c6x/libexec/gcc/tic6x-gchen-elf/5.0.0/lto-wrapper
Target: tic6x-gchen-elf
Configured with: ../gcc-c6x/configure --target=tic6x-gchen-elf --disable-nls
--enable-languages=c --disable-threads --disable-shared --disable-libssp
--disable-libquadmath --disable-libgomp --disable-libatomic
--prefix=/upstream/release-c6x --without-headers
Thread model: single
gcc version 5.0.0 20150321 (experimental) (GCC)