[Bug bootstrap/66638] [6 Regression] profiledbootstrap failure on x86-64 with LTO

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
It is an assertion failure, only I had difficualty in reproducing the issue.  I
got below link error when doing profiledbootstrap with given configuration
options:

/tmp/cc3NzkDN.ltrans0.ltrans.o: In function `read_md_files':
.build/gcc/../../gcc/gcc/read-md.c:1052: undefined reference to `xmalloc'
.build/gcc/../../gcc/gcc/read-md.c:1053: undefined reference to `htab_create'
.build/gcc/../../gcc/gcc/read-md.c:1054: undefined reference to `xmalloc'
.build/gcc/../../gcc/gcc/read-md.c:1055: undefined reference to `htab_create'
.build/gcc/../../gcc/gcc/read-md.c:1056: undefined reference to `xmalloc'
.build/gcc/../../gcc/gcc/read-md.c:1057: undefined reference to `htab_create'
.build/gcc/../../gcc/gcc/read-md.c:1059: undefined reference to `htab_create'
.build/gcc/../../gcc/gcc/read-md.c:1063: undefined reference to
`unlock_std_streams'
.build/gcc/../../gcc/gcc/read-md.c:1131: undefined reference to
`fopen_unlocked'
/tmp/cc3NzkDN.ltrans0.ltrans.o: In function
`_ZL20handle_toplevel_filePFviPKcE.constprop.1':
.build/gcc/../../gcc/gcc/read-md.c:1003: undefined reference to `lbasename'
.build/gcc/../../gcc/gcc/read-md.c:1007: undefined reference to `xstrndup'
/tmp/cc3NzkDN.ltrans0.ltrans.o: In function `parse_include(char const*)':
.build/gcc/../../gcc/gcc/read-md.c:1019: undefined reference to `xmalloc'
/tmp/cc3NzkDN.ltrans1.ltrans.o: In function `read_name(md_name*)':
.build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find'
.build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find'
.build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find'
.build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find'
.build/gcc/../../gcc/gcc/read-md.c:429: undefined reference to `htab_find'

I used ubuntu 12.04 system.  Anything wrong?

[Bug c++/66662] New: Request: Change #error directive displaying

[hvksmr1996 at gmail dot com]

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

Bug ID: 2
   Summary: Request: Change #error directive displaying
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hvksmr1996 at gmail dot com
  Target Milestone: ---

For example:

My code:
  #error my error

My console display:
  main.cpp:2:2: error: #error my error
   #error my error
^

As you can see, "#error my error" is displayed two times, it looks bad (with me
at least).

[Bug c/66658] missing -Wunused-value negating a function result in a comma expression

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
See also pr64639 (which this bug may be a duplicate of).

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

[P at draigBrady dot com]

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

--- Comment #7 from Pádraig Brady  ---
Created attachment 35852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35852&action=edit
reproducer

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
More to the point this might actually be a -fsanitize=address bug so reopening
for that issue.  By the way we know the alignment of the struct is 4 which
means loading a 4 byte would be valid.

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Pádraig Brady from comment #4)
> I should note that I worked around the issue by increasing the allocation
> for the structure on the heap up to a multiple of alignof(the_struct). See:
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=49078a78

That is not just a workaround but a correct patch.  The size of the memory
allocated needs to be a multiply of the alignment of the struct to be valid.

The reason why it works for you with your reduced testcase is because the
alignment of the struct is 1.

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

[P at draigBrady dot com]

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

--- Comment #4 from Pádraig Brady  ---
I should note that I worked around the issue by increasing the allocation for
the structure on the heap up to a multiple of alignof(the_struct). See:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=49078a78

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

[P at draigBrady dot com]

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

--- Comment #3 from Pádraig Brady  ---
Created attachment 35851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35851&action=edit
disassembly of forced good mem access

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

[P at draigBrady dot com]

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

--- Comment #2 from Pádraig Brady  ---
Created attachment 35850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35850&action=edit
disassembly of problematic mem access

[Bug c/66661] incorrect memory access in optimization with flexible array member

[P at draigBrady dot com]

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

--- Comment #1 from Pádraig Brady  ---
Created attachment 35849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35849&action=edit
summary code (does not reproduce issue)

[Bug c/66661] New: incorrect memory access in optimization with flexible array member

[P at draigBrady dot com]

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

Bug ID: 1
   Summary: incorrect memory access in optimization with flexible
array member
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: P at draigBrady dot com
  Target Milestone: ---

On a heap allocated structure, direct access to flexible array members with
optimization at -O2 can result in reads to memory beyond the heap object.
I.E. gcc assumes alignment/padding is allocated when accessing flexible array
members. The attached file is a summary of the code involved though does _not_
reproduce the issue.

To reproduce one can:

  git clone --depth=1 git://git.sv.gnu.org/coreutils.git
  cd coreutils/
  git checkout 53883af0
  export LSAN_OPTIONS=exitcode=0
  ./bootstrap && ./configure --quiet && \
  make -j8 AM_CFLAGS='-fsanitize=address -fsanitize=undefined'
  src/chmod a+rx ..

Also attached is the disassembly of the problematic code,
and for comparison good code achieved by using a (char*) cast
on the flexi array to force byte at a time access.

[Bug debug/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

  Component|c++ |debug

--- Comment #3 from Aldy Hernandez  ---
Mine.

[Bug bootstrap/65664] ARM bootstrap fails with --with-fpu=neon-vfpv4

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #5 from Ramana Radhakrishnan  ---
Fixed in 4.9.0 then.

[Bug debug/65771] ICE (in loc_list_from_tree, at dwarf2out.c:14964) on arm-linux-gnueabihf

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #15 from Ramana Radhakrishnan  ---
Jakub,

Does the patch in #c9 need testing for gcc 5 and then application ?

Ramana

[Bug target/65924] [6 Regression] ICE const_int_operand failed on arm-none-eabi

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan  ---
Fixed then ?

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[kkojima at gcc dot gnu.org]

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

--- Comment #38 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #37)
> Kaz, could you please add this to your test runs?  For me it's a bit
> difficult to do proper testing at the moment.

I'm testing the patch now.  I'll report back when it's done.

[Bug rtl-optimization/48808] ICE in spill_failure, at reload1.c:2113

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #5 from Ramana Radhakrishnan  ---
Fixed in 4.7.0

[Bug target/39585] GCC Generates Incorrect Stack Instructins for Interrupts When using -Os

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan  ---
Hmmm I wonder if this is a dup of PR49437 - I'll do some archeaology when I get
some time - however trunk is fixed currently.

[Bug target/49437] interrupt return pop sometimes corrupts sp

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #6 from Ramana Radhakrishnan  ---
fixed in 4.7.0

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||ramana at gcc dot gnu.org

--- Comment #34 from Ramana Radhakrishnan  ---
I guess waiting till someone tests on iwmmxt2 or proposes an actual tested
patch for this on trunk.

[Bug target/43722] ICE when passing NEON registers using const refrences

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |4.5.0

--- Comment #11 from Ramana Radhakrishnan  ---
Fixed in 4.5.0

[Bug debug/45447] ICE with `-g -femit-struct-debug-baseonly'

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #8 from Ramana Radhakrishnan  ---
fixed then with 4.4.6

[Bug rtl-optimization/49799] gcc arm generates illegal sbfx instruction

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||david.gilbert at linaro dot org

--- Comment #12 from Ramana Radhakrishnan  ---
*** Bug 48803 has been marked as a duplicate of this bug. ***

[Bug target/48803] arm: Bad assembler produced by bit extract/shift

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #5 from Ramana Radhakrishnan  ---
Duplicate then of PR49799... About time we closed this.

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

[Bug c/66660] New: [ia64] Speculative load not checked before use, leading to a NaT Consumption Vector interruption

[jakub at jermar dot eu]

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

Bug ID: 0
   Summary: [ia64] Speculative load not checked before use,
leading to a NaT Consumption Vector interruption
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at jermar dot eu
  Target Milestone: ---

Created attachment 35848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35848&action=edit
Reproducible test case.

I hit what appears to be a bug in handling speculative loads on Itanium in GCC
5.1.0. I am going to attach a simplified testcase derived from the latest
HelenOS sources, which reproduces the issue.

In the Ski IA-64 simulator running HelenOS, I can see the following sequence of
events wrt. r23:

 4407ff0:   09 b0 00 00 00 21   [MMI]   mov r22=r0
 4407ff6:   70 01 88 70 20 00   ld8.s r23=[r34] <=
speculative load, sets the NaT bit for r23
 4407ffc:   e0 08 2a 00 mov.i ar.lc=14;;
 4408000:   02 00 00 00 01 00   [MII]   nop.m 0x0
 4408006:   60 01 58 22 00 00   zxt2 r22=r22;;
 440800c:   82 78 20 79 shl r16=r8,r15
 4408010:   03 00 00 00 01 00   [MII]   nop.m 0x0
 4408016:   f0 78 38 80 3c e0   shr.u r15=r14,r15;;
 440801c:   01 78 44 00 zxt2 r15=r15;;
 4408020:   18 70 fc 21 3f 23   [MMB]   adds r14=-1,r16
 4408026:   00 78 74 10 23 00   st2 [r29]=r15
 440802c:   00 00 00 20 nop.b 0x0
 4408030:   01 00 50 34 98 11   [MII]   st8 [r26]=r20
 4408036:   50 11 3c 3c 29 60   extr.u r21=r15,1,31
 440803c:   12 78 b0 80 and r19=1,r15;;
 4408040:   0b c8 64 1c 0c 20   [MMI]   and r25=r25,r14;;
 4408046:   00 00 00 02 00 c0   nop.m 0x0
 440804c:   01 c8 44 00 zxt2 r14=r25;;
 4408050:   08 00 00 00 01 00   [MMI]   nop.m 0x0
 4408056:   60 72 98 00 40 00   add r38=r14,r38
 440805c:   00 00 04 00 nop.i 0x0
 4408060:   03 70 00 22 38 10   [MII]   ld8.s r14=[r17]
 4408066:   00 00 00 02 00 20   nop.i 0x0;;
 440806c:   05 30 59 00 sxt4 r41=r38;;
 4408070:   08 00 00 00 01 00   [MMI]   nop.m 0x0
 4408076:   00 00 00 02 00 00   nop.m 0x0
 440807c:   00 00 04 00 nop.i 0x0
 4408080:   09 80 00 24 38 10   [MMI]   ld8.s r16=[r18]
 4408086:   00 00 00 02 00 c0   nop.m 0x0
 440808c:   00 a0 1c e4 cmp.eq p6,p7=0,r20;;
 4408090:   f1 a0 fc 29 3f 23   [MIB] (p07) adds r20=-1,r20
 4408096:   00 00 00 02 80 03   nop.i 0x0
 440809c:   a0 00 00 43   (p07) br.cond.dpnt.few 4408130
;;
...
 4408130:   01 00 00 00 01 00   [MII]   nop.m 0x0
 4408136:   f0 00 54 22 00 00   zxt2 r15=r21
 440813c:   32 b1 38 80 or r16=r19,r22;;
 4408140:   00 00 3c 3a 88 11   [MII]   st2 [r29]=r15
 4408146:   60 81 f8 9c 29 00   dep.z r22=r16,1,15
 440814c:   02 80 44 00 zxt2 r16=r16
 4408150:   18 00 50 34 98 11   [MMB]   st8 [r26]=r20
 4408156:   00 00 00 02 00 00   nop.m 0x0
 440815c:   00 00 00 20 nop.b 0x0
 4408160:   11 00 00 00 01 00   [MIB]   nop.m 0x0
 4408166:   70 b9 60 00 40 00   add r23=r23,r24 <=
NaT bit not yet consumed
 440816c:   30 00 00 40 br.few 4408190
;;
...
 4408190:   10 00 00 00 01 00   [MIB]   nop.m 0x0
 4408196:   60 01 58 22 00 00   zxt2 r22=r22
 440819c:   00 00 00 20 nop.b 0x0
 44081a0:   09 b8 00 2e 08 10   [MMI]   ld2 r23=[r23]   <=
NaT consumption vector

In short, after doing the speculative load to r23, a conditional branch is
taken to code path which uses the speculatively-loaded register without first
running chk.s on it. So if the register has a NaT bit set (such as after a
deferred exception), there is going to be the NaT consumption vector
interruption on address 44081a0 above.

The issue did not show with GCC 4.8.1, but shows with GCC 5.1.0. Don't know
about the versions in between. The issue is also somewhat similar to an already
fixed Bug ID #53975. The same workaround applies, i.e.
-fno-selective-scheduling -fno-selective-scheduling2 will prevent the bug from
occurring.

[Bug c++/66659] New: Accepts invalid when undeduced context encountered deducing from a trailing parameter pack

[hstong at ca dot ibm.com]

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

Bug ID: 66659
   Summary: Accepts invalid when undeduced context encountered
deducing from a trailing parameter pack
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

In the call to "f" from "h" below, the deduction for T@0 should find both
"fptype" and "Func" and fail.

### SOURCE ():
template  struct A;

void g();
void g(bool);

typedef void (*fptype)();
struct Func { operator fptype(); } func;

template void f(A *ap, T ...b);

void h(A *ap) { f(ap, func, g); }


### COMPILER INVOCATION:
g++ -std=c++11 -c -x c++ -


### ACTUAL OUTPUT:
(Clean compile).


### EXPECTED OUTPUT:
(Error message).


### COMPILER VERSION INFO:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 6.0.0 20150623 (experimental) (GCC)

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #35 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #33)
> I see, thanks.  In this case, could you please add a comment e.g.:
> 
> ;; Loads of the GOTPC relocation values must not be optimized away
> ;; by e.g. any kind of CSE and must stay as they are.  Although there
> ;; are other various ways to ensure this, we use an artificial counter
> ;; operand to generate unique symbols.
> (define_expand "GOTaddr2picreg"

Good thinking.  I've committed the patch with your comment on trunk.

[Bug fortran/66528] [6 Regression] unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #7 from Manuel López-Ibáñez  ---
Fixed for GCC 6

[Bug fortran/66528] [6 Regression] unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
Author: manu
Date: Wed Jun 24 22:16:42 2015
New Revision: 224926

URL: https://gcc.gnu.org/viewcvs?rev=224926&root=gcc&view=rev
Log:
The problem is that diagnostic_action_after_output tries to delete the active
pretty-printer which tries to delete its output_buffer, which is normally
dynamically allocated via placement-new, but the output_buffer used by the
error_buffer of Fortran is statically allocated. Being statically allocated
simplifies a lot pushing/poping several instances of error_buffer.

The solution is to reset the active output_buffer back to the default one
before calling diagnostic_action_after_output. This is a bit ugly, because this
function does use the output_buffer, however, at the point that Fortran calls
it, both are in an equivalent state, thus there is no visible difference.

gcc/testsuite/ChangeLog:

2015-06-24  Manuel López-Ibáñez  

PR fortran/66528
* gfortran.dg/maxerrors.f90: New test.

gcc/fortran/ChangeLog:

2015-06-24  Manuel López-Ibáñez  

PR fortran/66528
* error.c (gfc_warning_check): Restore the default output_buffer
before calling diagnostic_action_after_output.
(gfc_error_check): Likewise.
(gfc_diagnostics_init): Add comment.

Added:
trunk/gcc/testsuite/gfortran.dg/maxerrors.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/testsuite/ChangeLog

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[matt at bitbashing dot io]

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

--- Comment #17 from Matt Kline  ---
Thanks for the info and such a quick response! I'll see if I can do the
required legwork.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #34 from Kazumoto Kojima  ---
Author: kkojima
Date: Wed Jun 24 22:11:04 2015
New Revision: 224925

URL: https://gcc.gnu.org/viewcvs?rev=224925&root=gcc&view=rev
Log:
PR target/66563
* [SH] Add a new operand to GOTaddr2picreg so to avoid CSE.  Modify caller
  of gen_GOTaddr2picreg.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez  ---
(In reply to Matt Kline from comment #15)
> > Fixed for GCC 6.
> 
> May I ask why this is being deferred until GCC 6.x? I'll readily admit that
> I'm not well-versed in the GCC release cycle, but this seems like a trivial
> enhancement and would be useful immediately. My team has been bitten by
> these silent conversions, and -Wconversion on Clang currently provides a
> similar warning.

GCC 6 is the next development release, which will be released early next year.
GCC 5 is the current stable release and, normally, only bugfixes are added to
it. If you wish to propose a backport, you'll need to write to the release
managers (for example, by writing to gcc@) and ask for permission, then you
need to do (or find someone to do) the backport, test it and commit it.

I'd rather have two new features in GCC 6 than one new feature in both GCC 5
and GCC 6, thus I (and likely others) prefer to dedicate my time to fixing
other things (and there is a lot of work to do:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps)
rather than on back-porting new features.

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[matt at bitbashing dot io]

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

Matt Kline  changed:

   What|Removed |Added

 CC||matt at bitbashing dot io

--- Comment #15 from Matt Kline  ---
> Fixed for GCC 6.

May I ask why this is being deferred until GCC 6.x? I'll readily admit that I'm
not well-versed in the GCC release cycle, but this seems like a trivial
enhancement and would be useful immediately. My team has been bitten by these
silent conversions, and -Wconversion on Clang currently provides a similar
warning.

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #4 from Ramana Radhakrishnan  ---
Need to apply Aurelien's patch - looks like that's slipped through the cracks.

[Bug rtl-optimization/64172] [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ra
  Component|target  |rtl-optimization

--- Comment #17 from Ramana Radhakrishnan  ---
Really an rtl-optimization bug - Vlad are you considering a 4.9 backport given
this is a P2 ?

[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #27 from Ramana Radhakrishnan  ---
Fixed for 6.0

[Bug c/66658] New: missing -Wunused-value negating a function result in a comma expression

[msebor at gcc dot gnu.org]

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

Bug ID: 66658
   Summary: missing -Wunused-value negating a function result in a
comma expression
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wunused-value warning is documented to:
Warn whenever a statement computes a result that is explicitly not used.

There are two minor issues here:

1) The following test case shows that GCC misses the opportunity to diagnose
the NOT expression in the first operand of the comma expression:

$ cat /build/tmp/u.c && ~/bin/gcc-5.1.0/bin/g++ -Wunused-value -c -o/dev/null
/build/tmp/u.c
int foo (int, int = 0);

int bar (int a)
{
if (a && !foo (0), 1)
return 1;

return 0;
}

Clang diagnoses this code as one would expect.

The example isn't C++ specific but with default arguments it's easy to
accidentally write "... !foo (0), 1)" when "... foo (0, 1))" is intended.
Having GCC issue a warning will help find these types of mistakes.

2) The documentation is subtly incorrect in that it uses the term "statement"
when what it actually means "expression."  If it really meant statement then
expressions such as initializers of function default arguments such as in the
example below would be excluded (when they are not):

int a;
int foo (int, int = 0);
int bar (int, int = (a && !foo (0), 1));

[Bug other/58133] GCC should emit arm assembly following the unified syntax

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan  ---
Oh and Kyrylo fixed up vfp.md last year too. So it's only ARM state that
remains. I have a few patches in flight that I'm testing.

[Bug other/58133] GCC should emit arm assembly following the unified syntax

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan  ---
Thumb1 Fixed for 5.0 with Terry's work - see release notes 
https://gcc.gnu.org/gcc-5/changes.html


ARM state is a bit more involved.

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #9)
> I still think this is a latent bug in the way that Fortran is generating the
> PARAM_DECL for time, but if the Fortran maintainers are not interested in
> investigating that, then I could prepare a patch with any of the
> work-arounds I have proposed above as soon as a Fortran maintainer (someone
> that will approve the patch) chooses one.

Scratch that. Since the goal is to bluntly silence the warning, then the only
work-around I see is the one proposed in the previous comment. 

(It would be interesting to know at which GCC version or revision the warning
started appearing).

[Bug driver/66657] Feature request - assembly output from lto compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
What are you trying to do with the assembly after the fact?

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #8)
> > If so, then the ICE was not caused by my diagnostic changes, it just 
> > exposes a
> > problem that has been latent or introduced later. Thus, I'm not planning to
> > investigate further.
> 
> Well, I think that is caused by your diagnostic changes, but is due to a
> conflicting definition of -Wunused-parameter in C* and gfortran which now
> share the same code (?).

It could be when we changed Fortran options to use the common options
machinery. But that sounds strange anyway, because -Wunused-parameter would
have enabled the middle-end warning in any case. I cannot find any code that
disabled the warning before my changes. In fact, this same testcase in GCC
4.5.1 (way before my changes!) had the middle-end option enabled but it didn't
give any warning.

> I am not sure if it is too late or not to change the name of the option in
> one of the front end. If it is too late, is it possible for the fortran FE
> to rename internally the option before passing it to the ME?

It could simply set:

{
 int tmp_warn_unused_parameter = warn_unused_parameter;
 warn_unused_parameter = 0
 cgraph_node::finalize_function (fndecl, true);
 warn_unused_parameter= tmp_warn_unused_parameter;
}

But it seems quite ugly to me. It would be better to understand why the
middle-end thinks it is unused (perhaps Fortran needs to mark it as used or
mark it with TREE_NO_WARNING?).

In fact, the exact same code in GCC 4.5.1 has TREE_NO_WARNING set in the
PARAM_DECL corresponding to time, but I'm not sure where it is set.

The middle-end warning also shows that the location given by Fortran to the
PARAM_DECL is very poor.

I still think this is a latent bug in the way that Fortran is generating the
PARAM_DECL for time, but if the Fortran maintainers are not interested in
investigating that, then I could prepare a patch with any of the work-arounds I
have proposed above as soon as a Fortran maintainer (someone that will approve
the patch) chooses one.

[Bug driver/66657] Feature request - assembly output from lto compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>There should be a gcc command line option to generate the assembly language 
>output of the lto compiler. 

Use -save-temps.

[Bug driver/66657] New: Feature request - assembly output from lto compiler

[kalmquist1 at hotmail dot com]

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

Bug ID: 66657
   Summary: Feature request - assembly output from lto compiler
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kalmquist1 at hotmail dot com
  Target Milestone: ---

There should be a gcc command line option to generate the assembly language
output of the lto compiler.  The -S option doesn't do this because it prevents
the lto compilation phase from running at all.

Currently, the only way to accomplish this is to run the lto compiler directly,
as in the following example:

  ld -r -plugin /usr/lib/gcc/x86_64-linux-gnu/4.8/liblto_plugin.so \
 -plugin-opt=/bin/true -plugin-opt=-fresolution=out.res in1.o in2.o
  /usr/lib/gcc/x86_64-linux-gnu/4.8/lto1 -quiet \
 -fresolution=out.res -o out.s -O2 in1.o in2.o

This is ugly and undocumented.

[Bug c++/66654] [6 Regression] ice in digest_init_r, at cp/typeck2.c:1103

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed.

[Bug c++/65919] [5/6 Regression] GCC 5.1 with options "-g -std=c++14" fails to compile multiple lambdas used as default function parameters

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |5.2

--- Comment #3 from Jason Merrill  ---
Fixed on the trunk by one of the patches for bug 44282; I've backported the
relevant section.

[Bug c++/65919] [5/6 Regression] GCC 5.1 with options "-g -std=c++14" fails to compile multiple lambdas used as default function parameters

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 20:24:01 2015
New Revision: 224922

URL: https://gcc.gnu.org/viewcvs?rev=224922&root=gcc&view=rev
Log:
PR c++/65919
* mangle.c (mangle_decl): Always SET_IDENTIFIER_GLOBAL_VALUE.
(decl_implicit_alias_p): Split out from maybe_remove_implicit_alias.
* cp-tree.h (DECL_REALLY_EXTERN): Handle null DECL_LANG_SPECIFIC.

Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/cp-tree.h
branches/gcc-5-branch/gcc/cp/mangle.c
branches/gcc-5-branch/gcc/testsuite/g++.dg/abi/mangle58.C

[Bug c++/66656] static constexpr array member: cannot get size via constexpr function

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  ---
The compiler/linker is right: You still need to provide a definition for the
second static data member. Providing an initializer does not provide such a
definition. To fix your problem, just add the line

constexpr X::item X::arr1[];

to your code.

This is not a defect.

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 20:23:53 2015
New Revision: 224921

URL: https://gcc.gnu.org/viewcvs?rev=224921&root=gcc&view=rev
Log:
PR c++/66647
* pt.c (dependent_type_p_r): Check for dependent alias template
specialization sooner.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/alias-decl-49.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/66644] Rejects C++11 in-class anonymous union members initialization

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  ---
The problem also exists in the current HEAD (Tested for gcc HEAD 6.0.0 20150623
(experimental))

[Bug c++/65879] [4.9/5/6 Regression] Bogus linkage errors for member class of anonymous class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed.

[Bug c++/66542] [4.9/5/6 Regression] [C++11] Can create static variable of type that has deleted destructor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for GCC 6; I tend not to backport fixes for invalid code bugs.

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 19:59:28 2015
New Revision: 224917

URL: https://gcc.gnu.org/viewcvs?rev=224917&root=gcc&view=rev
Log:
PR c++/66647
* pt.c (dependent_type_p_r): Check for dependent alias template
specialization sooner.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-49.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/66643] Missing compilation error for formatted data transfer without format

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #3 from Jerry DeLisle  ---
I will take this one.  It seems we could detect this as a useful diagnostic.

[Bug c++/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Marek Polacek  ---
Started with r224161.

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #8 from Segher Boessenkool  ---
Okay, looking.

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> If so, then the ICE was not caused by my diagnostic changes, it just exposes a
> problem that has been latent or introduced later. Thus, I'm not planning to
> investigate further.

Well, I think that is caused by your diagnostic changes, but is due to a
conflicting definition of -Wunused-parameter in C* and gfortran which now share
the same code (?).

I am not sure if it is too late or not to change the name of the option in one
of the front end. If it is too late, is it possible for the fortran FE to
rename internally the option before passing it to the ME?

[Bug c++/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
 Ever confirmed|0   |1

[Bug c++/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
Summary|ice in  |[6 Regression] ice in
   |gen_type_die_with_usage, at |gen_type_die_with_usage, at
   |dwarf2out.c:20876   |dwarf2out.c:20876

--- Comment #1 from Markus Trippelsdorf  ---
template  class A
{
  static __thread T a;
};

[Bug c++/66654] [6 Regression] ice in digest_init_r, at cp/typeck2.c:1103

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Marek Polacek  ---
Started with r224289.

[Bug c++/66654] [6 Regression] ice in digest_init_r, at cp/typeck2.c:1103

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
 CC||trippels at gcc dot gnu.org
Summary|ice in digest_init_r, at|[6 Regression] ice in
   |cp/typeck2.c:1103   |digest_init_r, at
   ||cp/typeck2.c:1103
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
class A {
  A();
};
class B {
  A r{r};
};

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #5)
> If I understand correctly the above statement, -Wunused-parameter should not
> emit a warning for the test in comment 0: there is no parameter. The warning
> should be issued with -Wunused-dummy-argument

If so, then the ICE was not caused by my diagnostic changes, it just exposes a
problem that has been latent or introduced later. Thus, I'm not planning to
investigate further.

If it is possible to generate a valid warning that triggers the same ICE, then
we should consider one of the options I have proposed above. From your
explanation above, it seems likely that Fortran doesn't ever want to get the
middle-end warning (which makes me wonder why this warning is given in the
middle-end to begin with!). Thus another (ugly?) fix may be to disable the
warning (all warnings?) completely around calls to finalize_function.

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
Another alternative is to add support for printing %D to gfc_format_decoder, it
is a matter of adding something like:

case 'D':
if (DECL_NAME (t))
{
  pp_string (pp, lang_hooks.decl_printable_name (t, 2));
  return true;
}

[Bug c++/51911] [C++11] G++ accepts new auto { list }

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-06-24
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Mine.

[Bug c++/66656] New: static constexpr array member: cannot get size via constexpr function

[g5834847 at trbvm dot com]

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

Bug ID: 66656
   Summary: static constexpr array member: cannot get size via
constexpr function
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g5834847 at trbvm dot com
  Target Milestone: ---



#include 

template 
constexpr size_t array_size(const T (&)[N])
{
  return N;
}

class X {
public:
  struct item {
char const* const name;
int   price;
  };

  static const item arr0[2];
  static constexpr item arr1[3] = {{"asdf", 0}, {"qwer", 1}, {"zxcv", 2}};

  static size_t constexpr size0() {
return array_size(arr0);// perfect
  }

  static size_t constexpr size1() {
return array_size(arr1);// problem!!
  }

};

const X::item X::arr0[] = {{"asdf", 0}, {"qwer", 1}};

int main()
{
  X x;
  std::cout << x.size0() << std::endl; // perfect
  std::cout << x.size1() << std::endl; // ERROR IN THIS LINE (cannot link!??)
  return 0;
}




$ c++ -std=c++14 -o go go.cpp

/tmp/ccPGS4ZN.o: In function `X::size1()':
go.cpp:(.text._ZN1X5size1Ev[_ZN1X5size1Ev]+0x5): undefined reference to
`X::arr1'
collect2: error: ld returned 1 exit status

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> BTW, is the resulting warning actually correct?

According the gfortran manual

-Wunused-parameter
Contrary to gcc's meaning of -Wunused-parameter, gfortran's implementation of
this option does not warn about unused dummy arguments (see
-Wunused-dummy-argument), but about unused PARAMETER values. -Wunused-parameter
is implied by -Wextra if also -Wunused or -Wall is used. 

If I understand correctly the above statement, -Wunused-parameter should not
emit a warning for the test in comment 0: there is no parameter. The warning
should be issued with -Wunused-dummy-argument

pr66605.f90:5:25:

 SUBROUTINE sub (neq, time, y, dydt)
 1
Warning: Unused dummy argument 'time' at (1) [-Wunused-dummy-argument]

[Bug c++/66617] C++11 {brace} initialisation of virtually inherited derived class = failure to override base virtual function, unless all base ctors have same signature

[db0451 at gmail dot com]

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

--- Comment #5 from DB  ---
Created attachment 35847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35847&action=edit
-save-temps output files plus the triggering cpp file

see corresponding -v output added in latest comment. Please advise when this
issue has been received and reviewed. Thanks.

[Bug c++/66617] C++11 {brace} initialisation of virtually inherited derived class = failure to override base virtual function, unless all base ctors have same signature

[db0451 at gmail dot com]

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

--- Comment #4 from DB  ---
Attaching verbose output and tempfiles as recommended by bug reporting guide.




$ gcc -v -save-temps -std=c++11 virtual2.cpp -o virtual2.exe
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.9.2/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --with-gxx-include-dir=/mingw64/include/c++/4.9.2
--enable-bootstrap --with-arch=x86-64 --with-tune=generic
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-libatomic --enable-threads=posix --enable-graphite
--enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-cloog-backend=isl
--enable-version-specific-runtime-libs --disable-cloog-version-check
--disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib
--enable-checking=release --disable-rpath --disable-win32-registry
--disable-nls --disable-werror --disable-symvers --with-libiconv
--with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
--with-isl=/mingw64 --with-cloog=/mingw64 --with-pkgversion='Rev5, Built by
MSYS2 project' --with-bugurl=http://sourceforge.net/projects/msys2
--with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.9.2 (Rev5, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-o' 'virtual2.exe'
'-mtune=generic' '-march=x86-64'
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/cc1plus.exe -E -quiet -v
-D_REENTRANT virtual2.cpp -mtune=generic -march=x86-64 -std=c++11
-fpch-preprocess -o virtual2.ii
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory "C:/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/msys64/mingw64/include/c++/4.9.2
 C:/msys64/mingw64/include/c++/4.9.2/x86_64-w64-mingw32
 C:/msys64/mingw64/include/c++/4.9.2/backward
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/include
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../include
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/include-fixed

C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-o' 'virtual2.exe'
'-mtune=generic' '-march=x86-64'
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/cc1plus.exe -fpreprocessed
virtual2.ii -quiet -dumpbase virtual2.cpp -mtune=generic -march=x86-64 -auxbase
virtual2 -std=c++11 -version -o virtual2.s
GNU C++ (Rev5, Built by MSYS2 project) version 4.9.2 (x86_64-w64-mingw32)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Rev5, Built by MSYS2 project) version 4.9.2 (x86_64-w64-mingw32)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 31108f4eb997d1c5310b0f90916e0ed9
virtual2.cpp: In constructor 'Right_Bottom::Right_Bottom(int, int, int, int)':
virtual2.cpp:51:6: error: cannot allocate an object of abstract type
'Left_Bottom'
   d{d}
  ^
virtual2.cpp:20:8: note:   because the following virtual functions are pure
within 'Left_Bottom':
 struct Left_Bottom: public virtual Left_Top
^
virtual2.cpp:12:15: note:   virtual void Left_Top::pure_virtual() const
  virtual void pure_virtual() const = 0;
   ^
virtual2.cpp:51:6: error: cannot allocate an object of abstract type
'Right_Top'
   d{d}
  ^
virtual2.cpp:31:8: note:   because the following virtual functions are pure
within 'Right_Top':
 struct Right_Top: public virtual Left_Top
^
virtual2.cpp:12:15: note:   virtual void Left_Top::pure_virtual() const
  virtual void pure_virtual() const = 0;
   ^

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
This is the warning we get when "fixed":

/home/manuel/test3/src/gcc/testsuite/gfortran.dg/wunused-parameter.f90:8:0:

 SUBROUTINE sub (neq, time, y, dydt)
^
Warning: unused parameter ‘time’ [-Wunused-parameter]

There is no such warning with 4.3.1

[Bug target/66655] New: [5.1 Regression] miscompilation due to ipa-ra on MinGW

[amonakov at gcc dot gnu.org]

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

Bug ID: 66655
   Summary: [5.1 Regression]  miscompilation due to ipa-ra on
MinGW
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-w64-mingw32

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

Attached is a testcase that, when compiled with a MinGW GCC 5.1, aborts on
execution.  Swapping the order of .o files in the final link, or compiling
main.cc with -O2 will produce a correct executable.

The failure is caused by interplay of -fipa-ra (enabled by default at -O2) and
MinGW's treatment of symbols that would normally be weak on ELF platforms.

When compiling c.cc, ipa-ra does not save/restore %rax around the call to
S::set (a static inline class method), apparently since the body emitted in
that translation unit does not indeed clobber %rax and is not considered
replaceable.  On Linux, S::set is weak and optimization is not performed. 
However, S::set is also emitted when compiling main.cc, and its copy in main.o
clobbers %rax since optimization is not enabled. During final link, the copy of
S::set from main.o is used, producing a broken executable.

(this issue is reduced from a miscompiled Clang produced by mingw-w64 5.1
cross-compiler)

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
BTW, is the resulting warning actually correct?

[Bug c++/66654] New: ice in digest_init_r, at cp/typeck2.c:1103

[dcb314 at hotmail dot com]

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

Bug ID: 66654
   Summary: ice in digest_init_r, at cp/typeck2.c:1103
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 35845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35845&action=edit
gzipped C++ source code

For gcc trunk dated 20150624, I get

$ ../results/bin/gcc -c -std=c++11 bug214.cc
In file included from
/home/dcb/rpmbuild/BUILD/MuseScore-2.0.0/libmscore/stafftext.h:18:0,
 from
/home/dcb/rpmbuild/BUILD/MuseScore-2.0.0/libmscore/plugins.cpp:34:
/home/dcb/rpmbuild/BUILD/MuseScore-2.0.0/libmscore/staff.h:118:44: internal
compiler error: in digest_init_r, at cp/typeck2.c:1103
   QColor _color  { MScore::defaultColor };
^
0x690163 digest_init_r
../../src/trunk/gcc/cp/typeck2.c:1103
0x692e40 digest_init_flags(tree_node*, tree_node*, int)
../../src/trunk/gcc/cp/typeck2.c:1154
0x692e40 digest_nsdmi_init(tree_node*, tree_node*)
../../src/trunk/gcc/cp/typeck2.c:1170
0x70b4a2 cp_parser_late_parse_one_default_arg
../../src/trunk/gcc/cp/parser.c:24304

[Bug c++/66653] New: ice in gen_type_die_with_usage, at dwarf2out.c:20876

[dcb314 at hotmail dot com]

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

Bug ID: 66653
   Summary: ice in gen_type_die_with_usage, at dwarf2out.c:20876
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 35844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35844&action=edit
gzipped C++ source code

For gcc trunk dated 20150624, I get the following error:

$ ../results/bin/gcc -g -c bug213.cc
cc1plus: internal compiler error: in gen_type_die_with_usage, at
dwarf2out.c:20876
0x9d2f41 gen_type_die_with_usage
../../src/trunk/gcc/dwarf2out.c:20876
0x9d29fd gen_type_die_with_usage
../../src/trunk/gcc/dwarf2out.c:20791
0x9d3276 gen_type_die
../../src/trunk/gcc/dwarf2out.c:20887
0x9d0dc4 gen_decl_die
../../src/trunk/gcc/dwarf2out.c:21496
0x9d1a2c dwarf2out_decl
../../src/trunk/gcc/dwarf2out.c:21923
0x93a0e2 analyze_functions
../../src/trunk/gcc/cgraphunit.c:1153
0x93a520 symbol_table::finalize_compilation_unit()
../../src/trunk/gcc/cgraphunit.c:2491
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug tree-optimization/66652] New: try_transform_to_exit_first_loop_alt generates incorrect loop

[vries at gcc dot gnu.org]

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

Bug ID: 66652
   Summary: try_transform_to_exit_first_loop_alt generates
incorrect loop
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

This testcase fails on trunk:
...
$ cat libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-5.c
/* { dg-do run } */
/* { dg-options "-O2 -ftree-parallelize-loops=2" } */

#include 
#include 
#include 

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

  i = UINT_MAX;
  do
{
  sum += i % 13;
  i++;
}
  while (i < n - 1);

  return sum;
}

int
main (void)
{
  unsigned int actual = f (0, 12);
  unsigned int expected = 4294967290;

  if (actual != expected)
abort ();

  return 0;
}
...

try_transform_to_exit_first_loop_alt changes the loop into this, and the loop
is never entered:
...
  i = UINT_MAX;
  while (i < n)
{
  sum += i % 13;
  i++;
}
...

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> I bet the bug is in whatever creates the mode mismatch.

I don't think so. Combiner somehow mixes up i1src, please see Comment #6.

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
Please note that combine already calls propagate_for_debug with wrong i1src:

reakpoint 3, internal_error (gmsgid=gmsgid@entry=0x1622837 "in %s, at %s:%d")
at /home/uros/gcc-svn/trunk/gcc/diagnostic.c:1266
1266{
(gdb) f 6
#6  0x0103276c in try_combine (i3=i3@entry=0x7171c580,
i2=, i2@entry=0x7171c540, i1=, i0=, i0@entry=0x0, 
new_direct_jump_p=new_direct_jump_p@entry=0x7fffd95c,
last_combined_insn=last_combined_insn@entry=0x7171c580) at
/home/uros/gcc-svn/trunk/gcc/combine.c:4386
4386   this_basic_block);
(gdb) list
4381  {
4382LOG_LINKS (i1) = NULL;
4383REG_NOTES (i1) = 0;
4384if (MAY_HAVE_DEBUG_INSNS)
4385  propagate_for_debug (i1, last_combined_insn, i1dest, i1src,
4386   this_basic_block);
4387SET_INSN_DELETED (i1);
4388  }
4389
4390if (i0)
(gdb) p debug_rtx (i1dest)
(reg:SI 94 [ D.1784 ])
$74 = void
(gdb) p debug_rtx (i1src)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
I bet the bug is in whatever creates the mode mismatch.

[Bug debug/66482] [6 Regression] ICE in gen_formal_parameter_die

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #7 from Aldy Hernandez  ---
Fixed in mainline.

Sorry, I forgot to include the PR in the commit message (though it is in the
ChangeLog), so bugzilla didn't pick it up:

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=224907

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Uroš Bizjak  ---
CC combine pass expert.

[Bug libfortran/66650] libgfortran: warning: left shift of negative value [-Wshift-negative-value]

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for r222892 and more recent revisions, not present for r222830.

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
This testcase exposes latent problem in combine pass in conjunction with debug.

We start with:

[...]

(insn 8 7 9 2 (set (reg:QI 95)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) pr66412.c:9 597 {*setcc_qi}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
(insn 9 8 11 2 (set (reg:SI 94 [ D.1784 ])
(zero_extend:SI (reg:QI 95))) pr66412.c:9 134 {*zero_extendqisi2}
 (expr_list:REG_DEAD (reg:QI 95)
(nil)))
(debug_insn 11 9 12 2 (var_location:HI g (subreg:HI (reg:SI 94 [ D.1784 ]) 0))
pr66412.c:9 -1
 (nil))
(debug_insn 12 11 13 2 (var_location:HI e (subreg:HI (ashift:SI (reg:SI 94 [
D.1784 ])
(const_int 1 [0x1])) 0)) pr66412.c:10 -1
 (nil))
(insn 13 12 14 2 (parallel [
(set (reg:SI 96 [ D.1783 ])
(ashift:SI (reg:SI 94 [ D.1784 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) pr66412.c:11 501 {*ashlsi3_1}
 (expr_list:REG_DEAD (reg:SI 94 [ D.1784 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 14 13 15 2 (set (reg:CCZ 17 flags)
(compare:CCZ (subreg:HI (reg:SI 96 [ D.1783 ]) 0)
(const_int 0 [0]))) pr66412.c:11 2 {*cmphi_ccno_1}
 (expr_list:REG_DEAD (reg:SI 96 [ D.1783 ])
(nil)))
(insn 15 14 16 2 (set (reg:QI 98)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) pr66412.c:11 597 {*setcc_qi}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))

[...]

and combine pass sequentially combines several insns into (insn 15):

Trying 8 -> 9:
Successfully matched this instruction:
(set (reg:SI 94 [ D.1784 ])
(eq:SI (reg:CCZ 17 flags)
(const_int 0 [0])))
allowing combination of insns 8 and 9
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i3 9: r94:SI=flags:CCZ==0
  REG_DEAD flags:CCZ
deferring rescan insn with uid = 9.

Trying 13 -> 14:
Successfully matched this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (ashift:SI (reg:SI 94 [ D.1784 ])
(const_int 1 [0x1]))
(const_int 0 [0])))
allowing combination of insns 13 and 14
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 13.
modifying insn i314: {flags:CCZ=cmp(r94:SI<<0x1,0);clobber scratch;}
  REG_DEAD r94:SI
deferring rescan insn with uid = 14.

Trying 9, 14 -> 15:
Failed to match this instruction:
(set (reg:QI 98)
(ne:QI (eq:SI (reg:CCZ 17 flags)
(const_int 0 [0]))
(const_int 0 [0])))
Splitting with gen_split_5441
Successfully matched this instruction:
(set (reg:QI 98)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0])))
allowing combination of insns 9, 14 and 15
original costs 4 + 4 + 4 = 12
replacement cost 4
deferring deletion of insn with uid = 14.

Calling propagate_for_debug for:

(debug_insn 11 9 12 2 (var_location:HI g (subreg:HI (reg:SI 94 [ D.1784 ]) 0))
pr66412.c:9 -1
 (nil))

we found (wrong) replacement for (reg:SI 94):

(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))

and we try to call simplify_gen_subreg with:

(gdb) f 3
#3  0x00aa2aaa in simplify_gen_subreg (outermode=HImode,
op=0x712aff00, innermode=SImode, byte=0) at
/home/uros/gcc-svn/trunk/gcc/simplify-rtx.c:5969
5969  newx = simplify_subreg (outermode, op, innermode, byte);
(gdb) p debug_rtx (op)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))

which crashes at:

#2  0x00aa261a in simplify_subreg (outermode=HImode, op=0x712aff00,
innermode=SImode, byte=0) at /home/uros/gcc-svn/trunk/gcc/simplify-rtx.c:5749
5749  gcc_assert (GET_MODE (op) == innermode

[Bug c++/66651] altivec.h + c++11 r

[timothee.ewart at epfl dot ch]

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

timocafe  changed:

   What|Removed |Added

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

--- Comment #2 from timocafe  ---
Hum thank you for the point. It fixes the issue, have a nice day

[Bug c++/66651] altivec.h + c++11 r

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 15:41:52 2015
New Revision: 224906

URL: https://gcc.gnu.org/viewcvs?rev=224906&root=gcc&view=rev
Log:
PR c++/66501
* init.c (vec_copy_assign_is_trivial): New.
(build_vec_init): Use it.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/rv-array1.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/init.c

[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 15:41:10 2015
New Revision: 224905

URL: https://gcc.gnu.org/viewcvs?rev=224905&root=gcc&view=rev
Log:
PR c++/66501
* init.c (vec_copy_assign_is_trivial): New.
(build_vec_init): Use it.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/rv-array1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/init.c

[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 15:40:08 2015
New Revision: 224904

URL: https://gcc.gnu.org/viewcvs?rev=224904&root=gcc&view=rev
Log:
PR c++/66501
* class.c (type_has_nontrivial_assignment): Remove.
* cp-tree.h: Remove declaration.
* init.c (vec_copy_assign_is_trivial): New.
(build_vec_init): Use it.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c

[Bug c++/66651] altivec.h + c++11 r

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
I believe that is a user error.
When using altivec.h and -maltivec in C++, you should either use the non-iso
-std modes like -std=gnu++11 or -std=gnu++98 or -std=gnu++14, or
#undef vector
#undef bool
after including altivec.h, or -D__APPLE_ALTIVEC__.  In iso modes without
-D__APPLE_ALTIVEC__, vector/bool are not contextual macros, but normal macros,
which is of course totally incompatible with all of the STL.

[Bug c++/65750] [4.9/5 Regression] misinterpret in a virtual member function with a C++11 style function signature

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c++/65750] [4.9/5 Regression] misinterpret in a virtual member function with a C++11 style function signature

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jun 24 15:11:06 2015
New Revision: 224901

URL: https://gcc.gnu.org/viewcvs?rev=224901&root=gcc&view=rev
Log:
/cp
2015-06-24  Adam Butcher  

PR c++/65750
* parser.c (cp_parser_simple_type_specifier): Don't synthesize
implicit template parm if 'auto' is a placeholder for trailing
return type.

/testsuite
2015-06-24  Adam Butcher  

PR c++/65750
* g++.dg/cpp0x/trailing11.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/trailing11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66651] New: altivec.h + c++11 r

[timothee.ewart at epfl dot ch]

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

Bug ID: 66651
   Summary: altivec.h + c++11 r
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timothee.ewart at epfl dot ch
  Target Milestone: ---

#include 
#include 
int main(){

}

hch058@jupp30:~/miniapps/ll-counter$ g++ --version
g++ (Ubuntu 4.9.1-16ubuntu6) 4.9.1
Copyright (C) 2014 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.

hch058@jupp30:~/miniapps/ll-counter$ g++ -std=c++11 -maltivec main.cpp
In file included from main.cpp:2:0:
/usr/include/c++/4.9/limits:195:57: error: cannot convert ‘bool’ to ‘const
__vector(4) __bool int’ in initialization
 static _GLIBCXX_USE_CONSTEXPR bool is_specialized = false;


machine: Power8 machine boot in little_endian, Ubuntu 14.10

[Bug tree-optimization/66642] transform_to_exit_first_loop_alt doesn't use result of low iteration count loop

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 35843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35843&action=edit
[2/2] Tentative patch

[Bug tree-optimization/66642] transform_to_exit_first_loop_alt doesn't use result of low iteration count loop

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 35842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35842&action=edit
[1/2] Tentative patch

[Bug libfortran/66650] New: libgfortran: warning: left shift of negative value [-Wshift-negative-value]

[tschwinge at gcc dot gnu.org]

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

Bug ID: 66650
   Summary: libgfortran: warning: left shift of negative value
[-Wshift-negative-value]
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As of the changes in context of PR65179,
,
I'm seeing a bunch of -Wshift-negative-value warnings in the libgfortran build,
for example:

In file included from [...]/libgfortran/intrinsics/cshift0.c:26:0:
[...]/libgfortran/intrinsics/cshift0.c: In function 'cshift0':
[...]/libgfortran/libgfortran.h:408:48: warning: left shift of negative
value [-Wshift-negative-value]
   ((~((index_type) 0) >> GFC_DTYPE_SIZE_SHIFT) << GFC_DTYPE_SIZE_SHIFT)
^
[...]/libgfortran/libgfortran.h:409:35: note: in expansion of macro
'GFC_DTYPE_SIZE_MASK'
 #define GFC_DTYPE_TYPE_SIZE_MASK (GFC_DTYPE_SIZE_MASK |
GFC_DTYPE_TYPE_MASK)
   ^
[...]/libgfortran/libgfortran.h:411:52: note: in expansion of macro
'GFC_DTYPE_TYPE_SIZE_MASK'
 #define GFC_DTYPE_TYPE_SIZE(desc) ((desc)->dtype &
GFC_DTYPE_TYPE_SIZE_MASK)
^
[...]/libgfortran/intrinsics/cshift0.c:94:15: note: in expansion of macro
'GFC_DTYPE_TYPE_SIZE'
   type_size = GFC_DTYPE_TYPE_SIZE (array);
   ^

Unless this will be resolved by demoting the warning (I have not reviewed the
recent discussion, such as PR66066,
),
I supposed this should be fixed in libgfortran/libgfortran.h, perhaps by making
index_type an unsiged type if that's possible?

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

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

--- Comment #33 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #32)

I see, thanks.  In this case, could you please add a comment e.g.:

;; Loads of the GOTPC relocation values must not be optimized away
;; by e.g. any kind of CSE and must stay as they are.  Although there
;; are other various ways to ensure this, we use an artificial counter
;; operand to generate unique symbols.
(define_expand "GOTaddr2picreg"

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #37 from Oleg Endo  ---
(In reply to Oleg Endo from comment #36)
> It seems the tstsi peephole is still wrong.  While working on AMS the
> following example:
> 
> int test (char* x, char* y, int z)
> {
>   return ((x[2] & x[3]) == 0) + z;
> }
> 
> silently produced wrong code by omitting one of the two mem loads.  After an
> update to the current trunk it results in
> 
> sh_tmp.cpp: In function 'int test(char*, char*, int)':
> sh_tmp.cpp:6:1: error: insn does not satisfy its constraints:
>  }
>  ^
> (insn 88 69 89 2 (set (reg:SI 1 r1)
> (sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 4 r4 [orig:169 x ]
> [169])
> (const_int 3 [0x3])) [0 MEM[(char *)x_1(D) + 3B]+0 S1
> A8]))) sh_tmp.cpp:5 232 {*extendqisi2_compact_mem_disp}
>  (nil))
> 
> which I think is the same as PR 66611.  The tstsi related peephole at line
> 14709 is causing the trouble.

The peephole in question can't be used for code sequences that include QImode
or HImode mem loads of the operands.  The following fixes the issue by matching
the resulting insn pattern and the constraints while emitting the new peephole
insns.  I think it's good to do those full checks as opposed to checking for
the currently known problematic mem loads.  This way we an be sure that
whatever the "emit_insn (gen_rtx_SET ..." produces is actually valid code.

The problem exists on the 5 branch and on trunk.

Kaz, could you please add this to your test runs?  For me it's a bit difficult
to do proper testing at the moment.

Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 224565)
+++ gcc/config/sh/sh.md (working copy)
@@ -14727,8 +14727,19 @@
   if (REGNO (operands[1]) == REGNO (operands[2]))
   operands[2] = gen_rtx_REG (SImode, REGNO (operands[0]));

-  sh_check_add_incdec_notes (emit_insn (gen_rtx_SET (operands[2],
-operands[3])));
+  // We don't know what the new set insn will be in detail.  Just make sure
+  // that it still can be recognized and the constraints are satisfied.
+  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2], operands[3]));
+
+  recog_data_d prev_recog_data = recog_data;
+  bool i_invalid = insn_invalid_p (i, false); 
+  recog_data = prev_recog_data;
+  
+  if (i_invalid)
+FAIL;
+
+  sh_check_add_incdec_notes (i);
+
   emit_insn (gen_tstsi_t (operands[2],
  gen_rtx_REG (SImode, (REGNO (operands[1]);
 })
@@ -14755,8 +14766,19 @@
|| REGNO (operands[2]) == REGNO (operands[5]))"
   [(const_int 0)]
 {
-  sh_check_add_incdec_notes (emit_insn (gen_rtx_SET (operands[2],
-operands[3])));
+  // We don't know what the new set insn will be in detail.  Just make sure
+  // that it still can be recognized and the constraints are satisfied.
+  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2], operands[3]));
+
+  recog_data_d prev_recog_data = recog_data;
+  bool i_invalid = insn_invalid_p (i, false); 
+  recog_data = prev_recog_data;
+  
+  if (i_invalid)
+FAIL;
+
+  sh_check_add_incdec_notes (i);
+  
   emit_insn (gen_tstsi_t (operands[2],
  gen_rtx_REG (SImode, (REGNO (operands[1]);
 })

[Bug c++/66649] New: variable template specializations not being found

[public at alisdairm dot net]

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

Bug ID: 66649
   Summary: variable template specializations not being found
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: public at alisdairm dot net
  Target Milestone: ---

Created attachment 35841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35841&action=edit
C++ code that should compile in C++14 mode, but fails

The attached file shows a simple test case for variable templates that I
believe is correct, and passes with Clang:

template 
constexpr bool is_same_v = false;

template 
constexpr bool is_same_v = true;

template 
auto make() -> T;

template 
void AssertMakeSame() {
   static_assert( is_same_v, "Type should be the same as itself");
   static_assert( is_same_v()), T>, "make should produce the
same type");
};

int main() {
   AssertMakeSame();
// AssertMakeSame();  // Should be an error
   AssertMakeSame();
}


In gcc 5, I get an error that the partial specialization must be at namespace
scope, but this appears to be fixed in trunk.  However, all 4 static asserts
fire in both trunk and 5.

Tested with:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/6.0.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/gcc-6-20150614/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6-20150614_0'
Thread model: posix
gcc version 6.0.0 20150614 (experimental) (MacPorts gcc6 6-20150614_0) 


and with:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/5.1.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc5/gcc5/work/gcc-5.1.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc5 --includedir=/opt/local/include/gcc5
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-5 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-5
--with-gxx-include-dir=/opt/local/include/gcc5/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc5 5.1.0_1'
Thread model: posix
gcc version 5.1.0 (MacPorts gcc5 5.1.0_1)

[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Version|5.1.1   |6.0
Summary|Feature request C++: mark   |declare __func__ ,
   |__func__ , __FUNCTION__ &   |__FUNCTION__ &
   |__PRETTY_FUNCTION__ as  |__PRETTY_FUNCTION__ as
   |constexpr   |constexpr

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Simon Gleissner from comment #3)
> > If at all, this could only be provided as compiler extension.
> 
> Good point. Yes, i think this would be a adequate solution.
> 
> > (assuming making it constexpr doesn't break anything)
> 
> ... which IMHO could only be tested safely with an optional compiler switch.

Due to past negative experiences, compiler extensions are only accepted under
very careful consideration and if they do not conflict with an existing (or
future) standard. Extensions accepted under an optional compiler switch are
even more rare: They add another very rarely tested point of failure and
increment the complexity of the compiler for very little benefit. The best
option is: create a tentative implementation, test it (by compiling and testing
GCC, libstdc++, boost, QT, Clang and other large C++ code bases) and propose
its standardization.