[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to vries from comment #5)
> So the question is: should ifn_va_arg have ECF_NOTHROW?

Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE.

And at gimplify_va_arg_expr, the VA_ARG_EXPR tree is non-throwing:
...
(gdb) call debug_generic_expr (*expr_p )
VA_ARG_EXPR 
(gdb) call debug_tree (*expr_p )
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x764a7690
precision 32 min  max 
pointer_to_this >
sizes-gimplified unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x764c97e0
pointer_to_this >
side-effects
arg 0 
sizes-gimplified BLK
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x764cc888 domain
>
used tree_1 decl_5 BLK file test.cc line 13 col 25 size  unit size 
align 64 context >
test.cc:15:32>
(gdb) call tree_could_throw_p (*expr_p )
$1 = false
...

I'll bootstrap and reg-test this fix.

[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g

[rguenther at suse dot de]

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

--- Comment #30 from rguenther at suse dot de  ---
On Fri, 17 Apr 2015, jason at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
> 
> Jason Merrill  changed:
> 
>What|Removed |Added
> 
>  CC||jason at gcc dot gnu.org
> 
> --- Comment #29 from Jason Merrill  ---
> (In reply to Jakub Jelinek from comment #17)
> > Lambda functions aren't really nested functions in the tree-nested.c sense,
> > but still are so closely related to the functions they are nested in that
> > IMHO it would be desirable not to split them off into separate partitions,
> > not just temporarily for GCC 5 for debug info reasons.
> 
> Agreed.  decl_function_context of the lambda function should give you the
> containing function.

As far as I understood imposing constraints like this to the partitioner
is hard because either you implement the same constraints into the inliner
as well or you eventually blow up partition sizes.

I'm also not 100% sure the issue we hit in dwarf2out is specific
to lambdas or nested functions - it might very well trigger with
regular C++ classes as well, just harder to reproduce.

So at least for branches I think my patch is the way to go - eventually
guarded with in_lto_p (if you really insist on that...)

[Bug target/65807] [5 Regression] ICE () on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.2

--- Comment #2 from Richard Biener  ---
Looks like debug related (we GC walk DIEs).

[Bug rtl-optimization/65805] [5 Regression] Chromium gets miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
   Target Milestone|--- |5.2
Summary|[5/6 Regression] Chromium   |[5 Regression] Chromium
   |gets miscompiled|gets miscompiled
  Known to fail||5.1.0

[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to vries from comment #6)
> (In reply to vries from comment #5)
> > So the question is: should ifn_va_arg have ECF_NOTHROW?
> 
> Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE.
> 
> And at gimplify_va_arg_expr, the VA_ARG_EXPR tree is non-throwing:

Is that always the case (try -fnon-call-exceptions)?  Then doing that looks
obvious.

Richard.

> (gdb) call debug_generic_expr (*expr_p )
> VA_ARG_EXPR 
> (gdb) call debug_tree (*expr_p )
>   type  type  size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x764a7690
> precision 32 min  max  0x764c5078 2147483647>
> pointer_to_this >
> sizes-gimplified unsigned DI
> size 
> unit size 
> align 64 symtab 0 alias set -1 canonical type 0x764c97e0
> pointer_to_this >
> side-effects
> arg 0  type  0x764cc738 __va_list_tag>
> sizes-gimplified BLK
> size 
> unit size 
> align 64 symtab 0 alias set -1 canonical type 0x764cc888
> domain >
> used tree_1 decl_5 BLK file test.cc line 13 col 25 size  0x764c5318 192> unit size 
> align 64 context >
> test.cc:15:32>
> (gdb) call tree_could_throw_p (*expr_p )
> $1 = false
> ...
> 
> I'll bootstrap and reg-test this fix.

[Bug tree-optimization/65797] [5 regression] IPA ICF causes function to be emitted with no debug line info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.2

[Bug middle-end/65796] unnecessary stack spills during complex numbers function calls

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
There is some older bug where I noticed the same issue.  It's basically an
artifact of the x86 calling conventions and GCC going through generic
argument setup code (and RTL optimizers not being able to optimize
spill + load into unpcklps).

That said, somebody needs to find the duplicate bugreport.

PR48607 is also related.

[Bug tree-optimization/65802] [6 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2335

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #7)
> (In reply to vries from comment #6)
> > (In reply to vries from comment #5)
> > > So the question is: should ifn_va_arg have ECF_NOTHROW?
> > 
> > Adding ECF_NOTHROW to ifn_va_arg also fixes the ICE.
> > 
> > And at gimplify_va_arg_expr, the VA_ARG_EXPR tree is non-throwing:
> 
> Is that always the case (try -fnon-call-exceptions)?  Then doing that looks
> obvious.
> 
> Richard.
> 

Yep, that's also the case with -fnon-call-exceptions:
...
(gdb) call debug_generic_expr (*expr_p)
VA_ARG_EXPR 
(gdb) call tree_could_throw_p (*expr_p )
$1 = false
(gdb) p flag_non_call_exceptions
$2 = 1
...

[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #5 from Richard Biener  ---
(In reply to rguent...@suse.de from comment #4)
> On Fri, 17 Apr 2015, hjl.tools at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
> > 
> > H.J. Lu  changed:
> > 
> >What|Removed |Added
> > 
> >  Status|WAITING |ASSIGNED
> > 
> > --- Comment #3 from H.J. Lu  ---
> > (In reply to Richard Biener from comment #2)
> > > Can't reproduce with r222165 and -O3 -funroll-loops -ffast-math.
> > 
> > But my bug report is against
> > 
> > -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
> > -fuse-linker-plugin
> > 
> > not -O3 -funroll-loops -ffast-math.  r222168 still has the same bug.
> 
> My bad - I uses
> 
> -O3 -funroll-loops -ffast-math -flto=jobserver 
> 
> linker-plugin gets used automatically for me and -fwhole-program
> should be a no-op with linker-plugin.  I can re-double-check that
> on Monday though.

Works for me again.

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin14.3 |*-apple-darwin*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-20
   Host|x86_64-apple-darwin14.3 |*-apple-darwin*
Summary|FAIL:   |[5/6 Regression] FAIL:
   |gcc.dg/debug/pr65771.c  |gcc.dg/debug/pr65771.c
   |-gstabs+* -O* (test for |-gstabs+* -O* (test for
   |excess errors)  |excess errors)
 Ever confirmed|0   |1
  Build|x86_64-apple-darwin14.3 |*-apple-darwin*

--- Comment #1 from Dominique d'Humieres  ---
Reduced range: no warning for r211652. Confirmed by Iain Sandoe on other darwin
targets (including powerpc-apple-darwin9).

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
So most likely r211689 ?  Can you attach assembly created by r211688 and
r211689 ?
Isn't this just a darwin linker bug?

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Created attachment 35361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35361&action=edit
assembly created by r211652

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Created attachment 35362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35362&action=edit
assembly created by r211698

The difference between the assembly created by r211652 and r211698 is the
single line

 .stabs"a:G(0,17)=ar(0,18)=r(0,18);0;0377;;0;9;(0,16)",32,0,6,0

[Bug debug/65807] [5 Regression] ICE () on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|target  |debug
   Target Milestone|5.2 |5.0

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
Ok, thus what shall we do? Shall we go back to my minimal patch which only
touched enums? https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00880.html

[Bug target/65810] powerpc64 alignment of r2 insufficient for loading long-double constants

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Why is this not seen on powerpc64-unknown-linux-gnu at
https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02317.html?

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Couldn't you simply turn the error_at into pedwarn?

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #4)
> Created attachment 35362 [details]
> assembly created by r211698
> 
> The difference between the assembly created by r211652 and r211698 is the
> single line
> 
>   .stabs  "a:G(0,17)=ar(0,18)=r(0,18);0;0377;;0;9;(0,16)",32,0,6,0

maybe that should have been transformed to :
.stabs   
"__emutls_v.a:G(0,17)=ar(0,18)=r(0,18);0;0377;;0;9;(0,16)",32,0,6,0

.. or sth similar, I"m a bit rusty on STABs format.

[Bug debug/65807] [5 Regression] ICE () on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 35363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35363&action=edit
gcc5-pr65807.patch

Untested obvious fix.  I'd say this is safe even for 5.1 at this point. 
Keeping uninitialized garbage in val_entry pointer is undesirable for GC.

[Bug tree-optimization/41089] [4.8/4.9/5/6 Regression] stdarg pass produces wrong code

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #58 from vries at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #57)
> See also PR64950

[ Adding alpha maintainer to cc. ]

Given the fix of PR64950, we should be able to remove the workaround committed
for this PR.

[Bug tree-optimization/41089] [4.8/4.9/5/6 Regression] stdarg pass produces wrong code

[ubizjak at gmail dot com]

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

--- Comment #59 from Uroš Bizjak  ---
(In reply to vries from comment #58)

> Given the fix of PR64950, we should be able to remove the workaround
> committed for this PR.

I have started bootstrap/regtest with the following revert:

--cut here--
Index: config/alpha/alpha.c
===
--- config/alpha/alpha.c (revision 28)
+++ config/alpha/alpha.c (working copy)
@@ -5957,10 +5957,6 @@ alpha_build_builtin_va_list (void)
integer_type_node);
   DECL_FIELD_CONTEXT (ofs) = record;
   DECL_CHAIN (ofs) = space;
-  /* ??? This is a hack, __offset is marked volatile to prevent
- DCE that confuses stdarg optimization and results in
- gcc.c-torture/execute/stdarg-1.c failure.  See PR 41089.  */
-  TREE_THIS_VOLATILE (ofs) = 1;

   base = build_decl (BUILTINS_LOCATION,
 FIELD_DECL, get_identifier ("__base"),
--cut here--

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
Well, at the time I think we agreed that we wanted to be strict at least about
enums... Otherwise, yes, we can do that plus setting ok = true in that case
too, thus collapsing the last two ifs (+ reverting the docs change and
adjusting the testsuite).

[Bug c++/65811] New: ice in vague_linkage_p

[dcb314 at hotmail dot com]

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

Bug ID: 65811
   Summary: ice in vague_linkage_p
   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

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

The attached code, when compiled by gcc trunk dated 20150418, does this

xcsv_tokens.in: In function ‘xt_mapping* in_word_set(const char*, unsigned
int)’
:
xcsv_tokens.in:28:5: internal compiler error: in vague_linkage_p, at
cp/decl2.c:
1866
0x703cde vague_linkage_p(tree_node*)
../../src/trunk/gcc/cp/decl2.c:1866
0x63230c maybe_commonize_var(tree_node*)
../../src/trunk/gcc/cp/decl.c:5200
0x65fff5 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../src/trunk/gcc/cp/decl.c:6692
0x750d6e cp_parser_init_declarator
../../src/trunk/gcc/cp/parser.c:17280

[Bug target/64134] (vector float){0, 0, b, a} Uses stores when it does not need to

[alalaw01 at gcc dot gnu.org]

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

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Apr 20 10:29:26 2015
New Revision: 29

URL: https://gcc.gnu.org/viewcvs?rev=29&root=gcc&view=rev
Log:
[AArch64] PR/64134: Make aarch64_expand_vector_init use 'ins' more often

gcc/:

PR target/64134
* config/aarch64/aarch64.c (aarch64_expand_vector_init): Load constant
and overwrite variable parts if <= 1/2 the elements are variable.

gcc/testsuite/:

PR target/64134
* gcc.target/aarch64/vec_init_1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/vec_init_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/65811] [6 Regression] ice in vague_linkage_p

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ice in vague_linkage_p  |[6 Regression] ice in
   ||vague_linkage_p
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
No, __emutls_v.a certainly is not a user variable, that is an artificial
object, the thread local variable of course lives elsewhere.
You could just drop the stabs for TLS vars on the floor, stabs really doesn't
have extensions to describe the TLS vars.  Like:
--- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
+++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
@@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree

   if (MEM_P (home) && GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
 {
+  if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
+return 0;
   if (TREE_PUBLIC (decl))
 {
   int offs;

The disadvantage of doing that is that (at least on x86_64-linux with
-gstabs+), ptype a etc. will stop working, but one couldn't inspect the
variables there either, you really need DWARF for that.
p &a
$3 = (struct S (*)[10]) 0x0
is of course wrong.  So, I'd classify this as a buggy Apple toolchain, but the
above patch might be just ok and not really break anything anyone cares about.

[Bug c/65812] New: gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[joe at perches dot com]

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

Bug ID: 65812
   Summary: gcc 4.9.1 doesn't warn about uninitialized variable
use declared in a switch/case statement when compiled
with -O
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joe at perches dot com

Created attachment 35365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35365&action=edit
sample code

Here is a small example:

$ cat t.c
struct foo {
   int bar[100];
};

void foo_1(void)
{
unsigned int m;
extern struct foo *array[100];
struct foo *a = array[m];

a = a;
}

void foo_2(void)
{
int i = 1;

switch (i) {
case 1: {
unsigned int m;
extern struct foo *array[100];
struct foo *a = array[m];

a = a;
break;
}
}
}

$

gcc warns properly about both foo_1 and foo_2 without -O

$ gcc -c -Wall t.c
t.c: In function ‘foo_1’:
t.c:9:14: warning: ‘m’ is used uninitialized in this function [-Wuninitialized]
  struct foo *a = array[m];
  ^
t.c: In function ‘foo_2’:
t.c:21:15: warning: ‘m’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   struct foo *a = array[m];
   ^
$

but gcc warns about foo_1 but not foo_2 with -O

$ gcc -c -Wall -O t.c
t.c: In function ‘foo_1’:
t.c:9:14: warning: ‘m’ is used uninitialized in this function [-Wuninitialized]
  struct foo *a = array[m];
  ^

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.1-16ubuntu6'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6)

[Bug c/65673] Compound literal with initializer for zero-sized array drops other initializers

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
The following seems to work and regtests cleanly.  But I have to say I'm
somewhat dubious now about changing this at all.  I suppose I should try to
compile e.g. the Linux kernel with this patch and see if anything breaks.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index ebe4c73..590e235 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -7565,7 +7565,7 @@ pop_init_level (location_t loc, int implicit,
   /* Silently discard empty initializations.  The parser will
  already have pedwarned for empty brackets.  */
   if (integer_zerop (constructor_unfilled_index))
-constructor_type = NULL_TREE;
+/* Do nothing.  */;
   else
 {
   gcc_assert (!TYPE_SIZE (constructor_type));

[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
This is because at the point where we warn we don't know that the code is
executed unconditionally and with optimization we don't warn about
maybe-uninitialized uses early.

Late we have removed all code as dead and thus do not warn either.

I'd say it works as intended (even though surprising).

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #6)
> No, __emutls_v.a certainly is not a user variable, that is an artificial
> object, the thread local variable of course lives elsewhere.
> You could just drop the stabs for TLS vars on the floor, stabs really
> doesn't have extensions to describe the TLS vars.  Like:
> --- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
> +++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
> @@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree
>  
>if (MEM_P (home) && GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
>  {
> +  if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
> +return 0;
>if (TREE_PUBLIC (decl))
>  {
>int offs;
> 
> The disadvantage of doing that is that (at least on x86_64-linux with
> -gstabs+), ptype a etc. will stop working, but one couldn't inspect the
> variables there either, you really need DWARF for that.
> p &a
> $3 = (struct S (*)[10]) 0x0
> is of course wrong.  So, I'd classify this as a buggy Apple toolchain,

there's nothing apple-specific about this - or even Darwin-specific.
The problem will exist for all the toolchains that use emutls (*iff* they are
interested in STABs debug).

AFAICT ld64 just detected an inconsistency that has gone un-noticed elsewhere, 
if that's really a ld64 bug we should file it… 

OTOH, I agree that there's probably little interest in STABs - even on Darwin
it's only relevant for the most ancient system on the horizon.

> the above patch might be just ok and not really break anything anyone cares
> about.

let's test that out.

[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This changed supposedly with r138933 and from that PR20644 I think it is quite
clear this is intentional.  The code in foo_2 is conditional (on a condition
later proved to be always true, though), so we really don't want to warn on it
early, because it might be in dead code, and we don't warn for it late because
it really is dead code, optimized away as nothing uses it.  If you add say a
global void *b; variable and change the a = a; statements to b = a;, then it
will warn even when optimizing, as the code won't be dead.

[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[joe at perches dot com]

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

--- Comment #3 from Joe Perches  ---
Thank you both for your very prompt replies.

It might be useful to have a -Wunused-eliminated type extra warning
though that might be very noisy.

[Bug go/65813] New: GO: bug347.go segment violation on S390x

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 65813
   Summary: GO: bug347.go segment violation on S390x
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: vogt at linux dot vnet.ibm.com
CC: cmang at google dot com

With current code from gcc_5_branch, the Go test bug347.go crashes by
dereferencing a null pointer:

-- snip --
$ gdb ./bug347.x
(gdb) run
Starting program: /home/vogt/src/git/gcc/build-go/gcc/testsuite/go/bug347.x 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x3fffaaa5910 (LWP 47868)]
[New Thread 0x3fffbba5910 (LWP 47867)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fffaaa5910 (LWP 47868)]
0x800019b8 in main.f ()
at /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/fixedbugs/bug347.go:22
22case <-t.c:  // THIS IS LINE 22
(gdb) bt
#0  0x800019b8 in main.f ()
at /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/fixedbugs/bug347.go:22
#1  0x80001a8c in main.main ()
at /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/fixedbugs/bug347.go:48
(gdb) p main.t
$1 = (struct {...} *) 0x0
-- snip --

It just dumps a core file and never calls the defered function (GOTRACEBACK is
not set).

[Bug c++/65811] [6 Regression] ice in vague_linkage_p

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

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

[Bug fortran/37131] inline matmul for small matrix sizes

[tkoenig at gcc dot gnu.org]

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

--- Comment #20 from Thomas Koenig  ---
First submitted patch:

https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00969.html

[Bug c++/65811] [6 Regression] ice in vague_linkage_p

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
struct foo { int i; };

static void fn1 ();
inline void
fn1 ()
{
  static struct foo a[1];
}

[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
r18 failed for me:

https://gcc.gnu.org/ml/gcc-regression/2015-04/msg00231.html

My GCC was configured with

--prefix=/export/gnu/import/git/gcc-test-spec-lto/usr --enable-clocale=gnu
--with-system-zlib --enable-shared --with-demangler-in-ld
--with-multilib-list=m32,m64,mx32 --with-fpmath=sse
--enable-languages=c,c++,fortran,lto

[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Mon, 20 Apr 2015, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
> 
> --- Comment #6 from H.J. Lu  ---
> r18 failed for me:
> 
> https://gcc.gnu.org/ml/gcc-regression/2015-04/msg00231.html
> 
> My GCC was configured with
> 
> --prefix=/export/gnu/import/git/gcc-test-spec-lto/usr --enable-clocale=gnu
> --with-system-zlib --enable-shared --with-demangler-in-ld
> --with-multilib-list=m32,m64,mx32 --with-fpmath=sse
> --enable-languages=c,c++,fortran,lto

Do you use gold or GNU ld (and which version)?  I don't use any
extra configure args for GCC and I'm using GNU ld 2.25.0 (that is,
sth from the 2.25 branch)

[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
I am using ld.bfd from binutils master branch.

[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Can you please try to reduce it to a testcase?

[Bug target/65810] powerpc64 alignment of r2 insufficient for loading long-double constants

[amodra at gmail dot com]

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

--- Comment #6 from Alan Modra  ---
It isn't seen most of the time because the failure happens only when r2 isn't
16-byte aligned (50% chance) and the r2 offset to a long double constant is
n*64k+32k-8 (0.012% chance per long double).  libgfortran stores paths for
error messages in .rodata, so source path can affect placement of those long
double constants.  I'm just lucky.

[Bug testsuite/60806] libstdc++ abi check should ignore missing TLS symbols

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #1 from Maxim Kuvyrkov  ---
Subscribing.  Just spent half-a-day figuring out why I get more TLS symbols on
aarch64-linux-gnu, than baseline show.

[Bug debug/65807] [5 Regression] ICE () on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr 20 13:30:01 2015
New Revision: 32

URL: https://gcc.gnu.org/viewcvs?rev=32&root=gcc&view=rev
Log:
PR debug/65807
* dwarf2out.c (add_AT_wide): Clear attr.dw_attr_val.val_entry.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug debug/65807] [5 Regression] ICE () on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr 20 13:31:02 2015
New Revision: 33

URL: https://gcc.gnu.org/viewcvs?rev=33&root=gcc&view=rev
Log:
PR debug/65807
* dwarf2out.c (add_AT_wide): Clear attr.dw_attr_val.val_entry.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/dwarf2out.c

[Bug libgomp/65814] New: [5/6 Regression] FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_on_device-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 65814
   Summary: [5/6 Regression] FAIL:
libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_on_dev
ice-1.c -DACC_DEVICE_TYPE_host_nonshm=1
-DACC_MEM_SHARED=0 execution test
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

[Bug libgomp/65814] [5/6 Regression] FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_on_device-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 execution test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Dup.

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

[Bug libgomp/65742] [5/6 Regression] Several libgomp.oacc-* failures after r221922.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
*** Bug 65814 has been marked as a duplicate of this bug. ***

[Bug debug/65807] [5/6 Regression] ICE () on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[5 Regression] ICE () on|[5/6 Regression] ICE () on
   |powerpc64le-linux-gnu   |powerpc64le-linux-gnu

--- Comment #6 from Jakub Jelinek  ---
Fixed for 5.1+.

[Bug c/65808] -pedantic -std=gnu11 results in warning for transparent_union usage

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I don't think it is a bug.  If you use -pedantic, it doesn't matter whether
-std=c11 or -std=gnu11 (the default) is in effect.
If you want to suppress the warning, use __extension__ as you did in the
test().

[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
So shouldn't this be INVALID rather than NEW?

[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

[mwahab at gcc dot gnu.org]

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

--- Comment #40 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #25)

> Documentation needs updating for sure... The rules have changed under us
> since originally SEQ_CST and sync were intended to be the same thing...
> Guess I shouldn't have tied our horse to the C++11 cart :-)

I've submitted a patch to try to update the __atomics documentation:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01025.html.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c   |tree-optimization

--- Comment #11 from Marek Polacek  ---
Looks more like a tree-optimization problem rather than C FE one.

[Bug c/65812] gcc 4.9.1 doesn't warn about uninitialized variable use declared in a switch/case statement when compiled with -O

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jakub Jelinek  ---
Sure.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gcc at robbertkrebbers dot nl]

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

--- Comment #12 from Robbert  ---
(In reply to Richard Biener from comment #10)
> and see how this will make PTA useless (all pointers passed to a function
> whose result might be used in a way to take advantage of an equality relation
> need to be considered pointing to anything).  [and then thorougly specify
> "take advantage of an equality relation"]
That is undesired indeed.

Only in case a pointer has been obtained via a construction that breaks
abstraction (for example, if it has been obtained via an int -> pointer casts,
or by poking bytes somewhere and then reinterpreting these as a pointer)
convervative PTA assumptions should be made.

[Bug c/65808] -pedantic -std=gnu11 results in warning for transparent_union usage

[equinox-gccbugs at diac24 dot net]

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

--- Comment #2 from David L.  ---
(In reply to Marek Polacek from comment #1)
> I don't think it is a bug.  If you use -pedantic, it doesn't matter whether
> -std=c11 or -std=gnu11 (the default) is in effect.
> If you want to suppress the warning, use __extension__ as you did in the
> test().

Hm.  It doesn't seem to produce a warning for the system's/glibc's wait()
definition, even though there is no __extension__ on that.  I guess that's
special-handling for system headers(?)

(Either way our target language is "C with gcc/clang/icc common extensions", so
I guess -pedantic is not appropriate...)

[Bug c++/65681] [c++-concepts] spurious ambiguous template instantiation error; regression from r211824

[andrew.n.sutton at gmail dot com]

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

--- Comment #1 from Andrew Sutton  ---
This is a good one. It is a regression, but it didn't have to do with the
resolution of partial specializations.

The substitution into requires-expressions was too eagerly doing full semantic
on analysis on simple and compound requirements, and that was causing a later
constraint check for a member function to fail unexpectedly.

Substituting a concrete type (say, MA2) into the constraint !CA2 is
generating a requirement for the expression t.MA2::mf(). When we go to check
that letter, we perform another substitution with the expectation that, in this
case, the result would be identical to the original since it's already been
resolved. However, the substitution actually rebuilds the call expression and
tries to resolve it as MA2::mf(t), which fails.

Anyways, this is resolved by deferring all semantic analysis to constraint
checking, and not allowing it to happen when we substitute into requirements.

Fixed in r36.

[Bug c/65808] -pedantic -std=gnu11 results in warning for transparent_union usage

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
(In reply to David L. from comment #2)
> Hm.  It doesn't seem to produce a warning for the system's/glibc's wait()
> definition, even though there is no __extension__ on that.  I guess that's
> special-handling for system headers(?)

Yes, likely: if you put the declarations in your test case into a header file
along with #pragma GCC system_header, you won't see any warnings.

I'm marking this as resolved.  If anyone thinks I'm wrong, please reopen.

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #7)
> (In reply to Jakub Jelinek from comment #6)

> > --- gcc/dbxout.c 2015-02-04 23:36:33.875630546 +0100
> > +++ gcc/dbxout.c 2015-04-20 12:27:14.579948127 +0200
> > @@ -2999,6 +2999,8 @@ dbxout_symbol_location (tree decl, tree
> >  
> >if (MEM_P (home) && GET_CODE (XEXP (home, 0)) == SYMBOL_REF)
> >  {
> > +  if (SYMBOL_REF_TLS_MODEL (XEXP (home, 0)) != TLS_MODEL_NONE)
> > +return 0;
> >if (TREE_PUBLIC (decl))
> >  {
> >int offs;

hmm .. not as things stand ..

(gdb) p debug_rtx(home)
(mem/c:BLK (symbol_ref:SI ("__emutls_v.a") [flags 0x1402] ) [0 __emutls_v.a+0 S16 A32])

(flags [5:3] contain the tls model which is 0 == TLS_MODEL_NONE in the case
above).

Current language:  auto; currently c++
(gdb) p debug_tree(decl)
 
unit size 
align 32 symtab 18 alias set -1 canonical type 0x14271d738 fields
 context 
pointer_to_this  chain >
BLK
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x14271d888
domain 
SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x14271d7e0 precision
32 min  max >>
addressable used public static BLK file
/GCC/gcc-trunk/gcc/testsuite/gcc.dg/debug/pr65771.c line 6 col 19 size
 unit size 
align 32 context 
value-expr 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x14271dd20 fields
>
asm_written used public static ignored BLK file
/GCC/gcc-trunk/gcc/testsuite/gcc.dg/debug/pr65771.c line 6 col 19 size
 unit size 
align 32 context  initial

(mem/c:BLK (symbol_ref:SI ("__emutls_v.a") [flags 0x1402] ) [0 __emutls_v.a+0 S16 A32])> chain >

(gdb) p decl->decl_common.ignored_flag
$3 = 0
(gdb) p decl_tls_model(decl)  
$4 = TLS_MODEL_NONE

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Then perhaps one needs to check

TREE_CODE (decl) == VAR_DECL
&& (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
&& decl_tls_model (decl) != TLS_MODEL_NONE

instead.

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
(In reply to Paolo Carlini from comment #5)
> Well, at the time I think we agreed that we wanted to be strict at least
> about enums... Otherwise, yes, we can do that plus setting ok = true in that
> case too, thus collapsing the last two ifs (+ reverting the docs change and
> adjusting the testsuite).

I think that for constants, we want it to be an error without -Wno-narrowing. 
I wonder if the best way to get that is to set pedantic_errors around the
pedwarn call?

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
Yes, I was thinking that in such cases clang does something we don't normally
do (ie, an hard error by default suppressible with a -Wno-*). Let me see if we
can achieve that as you suggested.

[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Jakub Jelinek from comment #9)
> Then perhaps one needs to check
> 
> TREE_CODE (decl) == VAR_DECL
> && (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
> && decl_tls_model (decl) != TLS_MODEL_NONE
> 
> instead.

except for:
(gdb) p decl_tls_model(decl)  
$4 = TLS_MODEL_NONE

which doesn't seem right .. but haven't got a chance to debug further right
now.

[Bug c/64918] invalid (?) warning when initializing structure

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Could be fixed with adding -Woverride-init-side-effects, but not sure if it's
worth it.

[Bug c++/65815] New: std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error

[andras.aszodi at csf dot ac.at]

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

Bug ID: 65815
   Summary: std::array initialization with initializer list: a =
{x,y,z} incorrectly flagged as syntax error
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andras.aszodi at csf dot ac.at

On Page 975 of "The C++ Programming Language", 4th edition, Bjarne Stroustrup
says:

"An array can be initialized by an initializer list:
array a1 = { 1, 2, 3 };"

and Clang (V 3.5) accepts it. However, G++ 4.9.2 thinks this is an error:

"error: array must be initialized with a brace-enclosed initializer
 const std::array _ar0val = {1.0, -1.0, 1.0};"

The ugly fix is:

#ifdef __GNUC__
const std::array _ar0val{{1.0, -1.0, 1.0}};
#else
const std::array _ar0val = {1.0, -1.0, 1.0};
#endif

but of course it is still a bug.

[Bug c++/65815] std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Hm?  This compiles just fine for me:

#include 
const std::array q1 = {1.0, -1.0, 1.0};
const std::array q2{{1.0, -1.0, 1.0}};

So can you provide a complete test case?

[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug middle-end/65788] [6 Regression] 416.gamess in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
Created attachment 35366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35366&action=edit
A testcase

[hjl@gnu-6 gcc]$ ./lto1 -quiet -dumpdir ./ -dumpbase gamess.ltrans29
-mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip
gamess.ltrans29.ltrans.o -O3 -O3 -version -fno-math-errno -fno-signed-zeros
-fno-trapping-math -fno-trapv -fno-openmp -fno-openacc -funroll-loops
-ffast-math -fwhole-program -fuse-linker-plugin -fltrans gamess.ltrans29.o -o
gamess.ltrans29.s
GNU GIMPLE (GCC) version 6.0.0 20150420 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 6.0.0 20150420 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.3 20140911 (Red Hat 4.8.3-7), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
cisgrd.fppized.f: In function ‘cisao’:
cisgrd.fppized.f:319:0: internal compiler error: in set_lattice_value, at
tree-ssa-ccp.c:524
0xd98eff set_lattice_value
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:524
0xd9fd16 visit_assignment
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:2272
0xd9ff1d ccp_visit_stmt
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:2341
0xe43186 simulate_stmt
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-propagate.c:348
0xe435c6 process_ssa_edge_worklist
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-propagate.c:462
0xe449dd ssa_propagate(ssa_prop_result (*)(gimple_statement_base*, edge_def**,
tree_node**), ssa_prop_result (*)(gphi*))
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-propagate.c:936
0xda00b5 do_ssa_ccp
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:2387
0xda016e execute
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-ccp.c:2420
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 target/65697] __atomic memory barriers not strong enough for __sync builtins

[mwahab at gcc dot gnu.org]

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

--- Comment #41 from mwahab at gcc dot gnu.org ---
(In reply to torvald from comment #38)
> (In reply to Andrew Macleod from comment #34)
> 
> Also, if you look at the IA-64 __sync_lock_release vs. GCC docs'
> __sync_lock_release, the latter is like x86/TSO.  Do you have any info on
> which other semantics __sync was supposed to adhere to?
> 
> One potential way to solve it would be to just require code that uses __sync
> to more or less implement an IA-64 or x86 memory model, modulo allowing
> compiler-reordering and optimization between adjacent non-__sync memory
> accesses.  This could be inefficient on ARM (see James' examples) and
> perhaps Power too (or not -- see Jakub's comments).

If the __sync barriers are as described in the GCC manual, that a barrier is
atomic and its restrictions apply to all data references, then the Aarch64
backend doesn't currently emit strong enough barriers.

For MEMMODEL_SEQ_CST, the problem was visible enough and the solution I
suggested (extending the set of available memmodel types) was simple enough
that the changes it would need could be justified. I don't think that's true
for the MEMMODEL_ACQUIRE case which seems to be much less likely to be seen and
would be rather more disruptive.

I believe that Aarch64 is the only current target where the code needs to be
strengthened. Since extending the set of memmodels is difficult to justify and
(IMO) so is resurrecting the __sync patterns, I suggest just adding a target
hook to allow the expansion of __sync calls to be overridden. That will allow
Aarch64 to set a target-specific memmodel value, as is currently allowed, which
can then be passed through the existing __atomics mechanisms in the middle
through to the Aarch64 backend. No other backend will need to be touched.

If it happens that future architectures have a similar problem then we can
reconsider whether any changes need to be made in the target-independent
expansions.

Does that sounds like a reasonable approach?

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  ---
Jason, as far as I can see *nowhere* else in the compiler we fiddle with
flag_pedantic_errors, all the tweaks I tried look super hackish to me :( If we
are Ok with just going back to pedwarns the attached passes testing...

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  ---
Created attachment 35367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35367&action=edit
Draft patch

[Bug c++/65815] std::array initialization with initializer list: a = {x,y,z} incorrectly flagged as syntax error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-04-20
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Works for me, please provide a complete testcase and your exact g++ command.

https://gcc.gnu.org/bugs/

[Bug go/65813] GO: bug347.go segment violation on S390x

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
I think you know this, but to be clear, the test is supposed to dereference a
null pointer, and then it's supposed to recover from the run time panic.

The program should unwind the stack for the signal and call __go_check_defer
which should invoke the deferred function.  Can you find out where that process
is going awry?

If the recover* tests pass, then this test ought to pass, or at least it ought
not to fail in this way.

[Bug go/65813] GO: bug347.go segment violation on S390x

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

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

--- Comment #2 from Dominik Vogt  ---
Sorry, this turned out to be the same problem we had with Glibc a while ago. 
Somehow the broken Glibc had been reactivated.  Not a Go or Gcc problem.

[Bug c/65606] Internal compiler error in linux-next 2015-03-25

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Marek Polacek  ---
Feedback not coming.

[Bug c++/65816] New: Constructor delegation does not perform zero-initialization

[dyp-cpp at gmx dot net]

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

Bug ID: 65816
   Summary: Constructor delegation does not perform
zero-initialization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dyp-cpp at gmx dot net

In the following program, I expect the object `t` to be zero-initialized via
constructor delegation. Clang++ does this, but g++ 6.0 2015-04-20 does not.

-

struct test
{
int m;

test() = default;
test(int) : test() {}
};

#include 

int main()
{
test t(0);
std::cout << t.m;
}

-

While C++14 IS [class.base.init]p6 is unclear about this, as far as I can tell,
paragraph 7 implies (in the parenthesized clause) that the constructor
`test(int)` is required to value-initialize the object:

> The expression-list or braced-init-list in a mem-initializer is used to 
> initialize the designated subobject (or, in the case of a delegating 
> constructor, the complete class object) according to the initialization rules 
> of 8.5 for direct-initialization.

The class `test` does not have a user-provided default constructor, hence
zero-initialization should be performed as per [dcl.init]p8.2

[Bug c++/65816] Constructor delegation does not perform zero-initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-20
 Ever confirmed|0   |1

[Bug tree-optimization/65658] Jump threading too pessimistic when optimizing for size

[law at gcc dot gnu.org]

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

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Mon Apr 20 17:13:52 2015
New Revision: 42

URL: https://gcc.gnu.org/viewcvs?rev=42&root=gcc&view=rev
Log:
PR tree-optimization/65658
* tree-ssa-threadupdate.c (redirection_block_p): Ignore clobber
statements too.

PR tree-optimization/65658
* gcc.dg/pr65658.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr65658.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug other/65732] stack overflow while demangling _ZNK7VectorTIfEmlIfvEES_IDTmlcvf_EcvT__EEERKS2_

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-20
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
_ZN23Parma_Polyhedra_Library9OR_MatrixINS_14Checked_NumberI10__gmp_exprIA1_12__mpz_structS4_ENS_26WRD_Extended_Number_Policy16any_row_iteratorIKS7_EpLImEENS_9Enable_IfIXgtcvT_ngLi1ELi0EERSB_E4typeESE_

_ZN2kjmlIllNS_1_15NanosecondLabelEEENS_8QuantityIDTmlcvT_Li1EcvT0_Li1EET1_EES4_NS3_IS5_S7_EE

[Bug plugins/65817] New: libcc1: ICE: SEGV: c_incomplete_type_error()

[jan.kratochvil at redhat dot com]

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

Bug ID: 65817
   Summary: libcc1: ICE: SEGV: c_incomplete_type_error()
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
CC: pmuldoon at redhat dot com
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

r30

Current libcc1 uses just: make_node (RECORD_TYPE)
which crashes on:
  if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
as TYPE_NAME (type) == NULL .

Actual:
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_PRE_GENERICIZE| libcc1plugin
PLUGIN_GGC_MARKING   | libcc1plugin
PLUGIN_PRAGMAS   | libcc1plugin
gdb command line:1:1: internal compiler error: Segmentation fault
0xb1c4af crash_signal
../../gccgitatsign/gcc/toplev.c:383
0x618794 c_incomplete_type_error(tree_node const*, tree_node const*)
../../gccgitatsign/gcc/c/c-typeck.c:282
0x623750 c_incomplete_type_error(tree_node const*, tree_node const*)
../../gccgitatsign/gcc/c/c-typeck.c:235
0x623750 build_component_ref(unsigned int, tree_node*, tree_node*)
../../gccgitatsign/gcc/c/c-typeck.c:2304
0x654fb3 c_parser_postfix_expression_after_primary
../../gccgitatsign/gcc/c/c-parser.c:7925
0x6478f6 c_parser_postfix_expression
../../gccgitatsign/gcc/c/c-parser.c:7715
0x649f5a c_parser_unary_expression
../../gccgitatsign/gcc/c/c-parser.c:6602
0x65122f c_parser_cast_expression
../../gccgitatsign/gcc/c/c-parser.c:6440
0x651412 c_parser_binary_expression
../../gccgitatsign/gcc/c/c-parser.c:6255
0x651f75 c_parser_conditional_expression
../../gccgitatsign/gcc/c/c-parser.c:6031
0x652560 c_parser_expr_no_commas
../../gccgitatsign/gcc/c/c-parser.c:5949

0x652c52 c_parser_expression
../../gccgitatsign/gcc/c/c-parser.c:8022
0x653689 c_parser_expression_conv
../../gccgitatsign/gcc/c/c-parser.c:8055
0x661978 c_parser_statement_after_labels
../../gccgitatsign/gcc/c/c-parser.c:5115
0x663173 c_parser_compound_statement_nostart
../../gccgitatsign/gcc/c/c-parser.c:4701
0x66399e c_parser_compound_statement
../../gccgitatsign/gcc/c/c-parser.c:4538
0x661a67 c_parser_statement_after_labels
../../gccgitatsign/gcc/c/c-parser.c:4964
0x663173 c_parser_compound_statement_nostart
../../gccgitatsign/gcc/c/c-parser.c:4701
0x66399e c_parser_compound_statement
../../gccgitatsign/gcc/c/c-parser.c:4538
0x65fc80 c_parser_declaration_or_fndef
../../gccgitatsign/gcc/c/c-parser.c:1982
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Compilation failed.

Expected:
gdb command line:1:1: error: invalid use of incomplete typedef ‘({anonymous})’

1586c8fbaf0116931ffacd1746a6540c81c2d438 GDB commit

[Bug plugins/65817] libcc1: ICE: SEGV: c_incomplete_type_error()

[jan.kratochvil at redhat dot com]

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

--- Comment #1 from Jan Kratochvil  ---
Created attachment 35368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35368&action=edit
GDB patch

GDB patch to crash GCC.

together with:
cat >1.c <

[Bug plugins/65817] libcc1: ICE: SEGV: c_incomplete_type_error()

[jan.kratochvil at redhat dot com]

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

--- Comment #2 from Jan Kratochvil  ---
Created attachment 35369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35369&action=edit
Attempted GCC fix.

With this GCC fix and the GDB reproducer it looks as fixed:

gdb command line:1:1: error: invalid use of incomplete typedef ‘({anonymous})’

But after running gdb.compile/compile.exp one gets another crash so this GCC
fix is probably not right.

compile code struct_object.selffield = &struct_object^M
gdb command line:1:1: error: cannot convert gdb type to gcc type^M
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.^M
Event| Plugins^M
PLUGIN_PRE_GENERICIZE| libcc1plugin^M
PLUGIN_GGC_MARKING   | libcc1plugin^M
PLUGIN_PRAGMAS   | libcc1plugin^M
gdb command line:1:1: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in plugin_build_add_field, at
libcc1/plugin.cc:533^M
0xd7d007 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)^M
../../gccgitatsign/gcc/tree.c:9350^M
0x7f61d20f1084 tree_class_check(tree_node*, tree_code_class, char const*, int,
char const*)^M
../../gccgitatsign/libcc1/../gcc/tree.h:2969^M
0x7f61d20ef461 plugin_build_add_field(cc1_plugin::connection*, unsigned long
long, char const*, unsigned long long, unsigned long, unsigned long)^M
../../gccgitatsign/libcc1/plugin.cc:533^M
0x7f61d20f6407 cc1_plugin::connection::do_wait(bool)^M
../../gccgitatsign/libcc1/connection.cc:144^M
0x7f61d20f12be cc1_plugin::connection::wait_for_result()^M
../../gccgitatsign/libcc1/connection.hh:72^M
0x7f61d20f1edd cc1_plugin::status cc1_plugin::call(cc1_plugin::connection*, char const*, int*, gcc_c_oracle_request,
char const*)^M
../../gccgitatsign/libcc1/rpc.hh:227^M
0x7f61d20ee778 plugin_binding_oracle^M
../../gccgitatsign/libcc1/plugin.cc:278^M
0x5fe398 i_symbol_binding^M
../../gccgitatsign/gcc/c/c-decl.c:268^M
0x5fe398 lookup_name(tree_node*)^M
../../gccgitatsign/gcc/c/c-decl.c:3896^M
0x645e44 c_lex_one_token^M
../../gccgitatsign/gcc/c/c-parser.c:363^M
0x663633 c_parser_peek_token^M
../../gccgitatsign/gcc/c/c-parser.c:440^M
0x663633 c_parser_next_token_is^M
../../gccgitatsign/gcc/c/c-parser.c:452^M
0x663633 c_parser_compound_statement_nostart^M
../../gccgitatsign/gcc/c/c-parser.c:4557^M
0x66399e c_parser_compound_statement^M
../../gccgitatsign/gcc/c/c-parser.c:4538^M
0x661a67 c_parser_statement_after_labels^M
../../gccgitatsign/gcc/c/c-parser.c:4964^M
0x663173 c_parser_compound_statement_nostart^M
../../gccgitatsign/gcc/c/c-parser.c:4701^M
0x66399e c_parser_compound_statement^M
../../gccgitatsign/gcc/c/c-parser.c:4538^M
0x65fc80 c_parser_declaration_or_fndef^M
../../gccgitatsign/gcc/c/c-parser.c:1982^M
0x669a97 c_parser_external_declaration^M
../../gccgitatsign/gcc/c/c-parser.c:1452^M
0x66a359 c_parser_translation_unit^M
../../gccgitatsign/gcc/c/c-parser.c:1339^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
Compilation failed.^M
(gdb) FAIL: gdb.compile/compile.exp: compile code struct_object.selffield =
&struct_object

BTW the GDB patch is wrong, it is used only as a reproducer of the GCC crash.

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  ---
I'm also attaching what I have for the forced pedantic-errors idea.

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  ---
Created attachment 35370
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35370&action=edit
Draft patch 2

[Bug tree-optimization/65658] Jump threading too pessimistic when optimizing for size

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Mon Apr 20 19:35:50 2015
New Revision: 47

URL: https://gcc.gnu.org/viewcvs?rev=47&root=gcc&view=rev
Log:
   PR tree-optimization/65658
* tree-ssa-threadupdate.c (redirection_block_p): Remove
redundant test for GIMPLE_ASSIGN in last change.

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

[Bug tree-optimization/65658] Jump threading too pessimistic when optimizing for size

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed with trunk commits.

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  ---
(In reply to Paolo Carlini from comment #11)
> Draft patch 2

I think let's go with this.  It's odd, but not complex and does what we want.

[Bug tree-optimization/65818] New: libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095

[danglin at gcc dot gnu.org]

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

Bug ID: 65818
   Summary: libiberty/vprintf-support.c:41:1: ICE: in expand_i
fn_va_arg_1, at tree-stdarg.c:1095
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  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

if [ x"-fPIC" != x ]; then \
  /test/gnu/gcc/objdir/./prev-gcc/xgcc
-B/test/gnu/gcc/objdir/./prev-gcc
/ -B/opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-6.0/hppa2
.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/lib/
-isystem
 /opt/gnu/gcc/gcc-6.0/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/gcc-6.
0/hppa2.0w-hp-hpux11.11/sys-include-c -DHAVE_CONFIG_H -g -O2  -I.
-I../../gc
c/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototype
s -pedantic  -fPIC ../../gcc/libiberty/vprintf-support.c -o
pic/vprintf-support.
o; \
else true; fi
../../gcc/libiberty/vprintf-support.c: In function
'libiberty_vprintf_buffer_siz
e':
../../gcc/libiberty/vprintf-support.c:41:1: internal compiler error: in
expand_i
fn_va_arg_1, at tree-stdarg.c:1095
 libiberty_vprintf_buffer_size (const char *format, va_list args)
 ^

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Paolo Carlini  ---
Ok, I'll commit it in an hour or so to trunk. Is it too late for 5.1?

[Bug go/65180] regression in gccgo testcase runtime/pprof on ppc64le, ppc64 following move to go 1.4 from 1.3

[boger at us dot ibm.com]

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

--- Comment #6 from boger at us dot ibm.com ---
I have verified this testcase now passes on ppc64le with today's gcc-5-branch
and with gcc trunk.

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Paolo Carlini from comment #13)
> Ok, I'll commit it in an hour or so to trunk. Is it too late for 5.1?

It is IMHO too late for that, but not too late for 5.2.

[Bug tree-optimization/65818] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Created attachment 35371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35371&action=edit
Preprocessed source

[Bug fortran/65819] New: overzealous checking in gfc_check_dependency for identical=true

[tkoenig at gcc dot gnu.org]

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

Bug ID: 65819
   Summary: overzealous checking in gfc_check_dependency for
identical=true
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org

Just ran across this while trying to cook up a test case for matrix inlining.

In the patch proposed for PR 37131, I have

  if (gfc_check_dependency (expr1, matrix_a, true)
  || gfc_check_dependency (expr1, matrix_b, true))
return 0;

In the test case, I want to do

  f(3,1:eight:2,:) = matmul(f(1,1:3,2:3), f(2,2:3,:))

where clearly the lhs does not depend on the rhs.  However, specifying true to
gfc_dep_dependency leads to

  if (identical)
return 1;

before any checking is done.  I'm not sure if there is a real-world test
case yet, but there will be one soon, so I'll keep this PR as a reminder.

[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Blocks||37131
   Severity|normal  |enhancement

[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules

[paolo at gcc dot gnu.org]

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

--- Comment #15 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Apr 20 21:46:59 2015
New Revision: 49

URL: https://gcc.gnu.org/viewcvs?rev=49&root=gcc&view=rev
Log:
/cp
2015-04-20  Paolo Carlini  

PR c++/65801
* typeck2.c (check_narrowing): In C++11 mode too, -Wno-narrowing
suppresses the diagnostic.

2015-04-20  Paolo Carlini  

PR c++/65801
* doc/invoke.texi ([-Wnarrowing]): Update.

/testsuite
2015-04-20  Paolo Carlini  

PR c++/65801
* g++.dg/cpp0x/Wnarrowing2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug other/65820] New: escape backslashes in .d file

[paul_robinson at playstation dot sony.com]

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

Bug ID: 65820
   Summary: escape backslashes in .d file
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul_robinson at playstation dot sony.com

gcc should escape backslashes when writing a .d file, because that's
what GNU make expects.

(Yes, I know special characters in filenames are a bad idea...)

There are various scenarios, this one seems to be the easiest to
demonstrate.

$ gcc --version
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 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.

$ make --version
GNU Make 3.81
Copyright (C) 2006  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.

This program built for x86_64-pc-linux-gnu
$ cat quote.c
#include "a\\b.h"
$ # BTW that's two backslashes, not one escaped backslash; C11 6.4.7.
$ touch ab.h
$ gcc -c -MMD quote.c
$ # But the .d file just copies the string literally.
$ cat quote.d
quote.o: quote.c a\\b.h

$ rm ab.h
$ # Make properly doesn't find the nonexistent file
$ make -f quote.d quote.o
make: *** No rule to make target `a\\b.h', needed by `quote.o'.  Stop.
$ # Accidentally create the wrong number of backslashes...
$ touch a\\b.h
$ # ...make will interpret a\\b.h as a\b.h, even though gcc doesn't.
$ make -f quote.d quote.o
cc-c -o quote.o quote.c
quote.c:1:18: fatal error: a\\b.h: No such file or directory
 #include "a\\b.h"
  ^
compilation terminated.
make: *** [quote.o] Error 1
$ 


If I modify the .d file to escape backslashes, it works properly.

$ cat quote.d
quote.o: quote.c ab.h
$ touch ab.h
$ ls
a\\b.h  quote.c  quote.d
$ make -f quote.d quote.o
cc-c -o quote.o quote.c
$

[Bug debug/65821] New: [4.8.2 regression] incorrect debug line # info for main

[chihin.ko at oracle dot com]

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

Bug ID: 65821
   Summary: [4.8.2 regression] incorrect debug line # info for
main
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chihin.ko at oracle dot com

this happen since 4.8.2, 4.9.0 also have same problem.

cat t.cc
==
  1 #include 
  2
  3 int b = 12;
  4
  5 inline void foo(const int &x = (b+3))
  6 {
  7 printf("%d\n", x);
  8 }   9
 10 inline void baz(const int &x = 200)
 11 {
 12 printf("%d\n", x);
 13 }
 14
 15 inline void bar(int &x = b)
 16 {  17 printf("%d\n", x);
 18 x = 100;
 19 printf("%d\n", x);
 20 }
 21
 22
 23 void
 24 bob(char *s = "hello")  25 {
 26 printf("%s\n", s);
 27 }  28
 29 int main()
 30 {
 31   foo();  32   baz();
 33   bar();
 34   bob();
 35   return 0;
 36 }

The line table for main is incorrect:

< 1><0x067e>DW_TAG_subprogram
  DW_AT_external  yes(1)
  DW_AT_name  "main"
  DW_AT_decl_file 0x0001 t.cc
  DW_AT_decl_line 0x001d
  DW_AT_type  <0x0491>
  DW_AT_low_pc0x0040129f
  DW_AT_high_pc   0x004012ff
.debug_line
---

0x0040129f  [  30, 0] NS
0x004012a7  [   5, 0] NS   < extra line info
0x004012b0  [  31, 0] NS
0x004012bf  [  32, 0] NS DI=0x1
0x004012d2  [  33, 0] NS
0x004012dc  [  34, 0] NS

This cause follwing problem:
(gdb) b main
Breakpoint 1 at 0x4006ea: file c++defargs3.cc, line 5.  <== should be line 31
(gdb) run
Starting program:
/workspace/chko/ws/dinstall/dbx_test/intel_S11_gcc482/c++defargs3.dbx,gcc/g47/a.out

Breakpoint 1, main () at c++defargs3.cc:5
5   inline void foo(const int &x = (b+3))

[Bug testsuite/65767] Test pr65276 failed on arm-none-eabi

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Apr 21 02:23:18 2015
New Revision: 55

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

PR testsuite/65767
* g++.dg/lto/pr65276_0.C: Change namespace std to std2.
* g++.dg/lto/pr65276_1.C: Change namespace std to std2.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/pr65276_0.C
trunk/gcc/testsuite/g++.dg/lto/pr65276_1.C

[Bug debug/65822] New: [4.8.2 regression] Used variant fun names in dwarf info for CTORs

[chihin.ko at oracle dot com]

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

Bug ID: 65822
   Summary: [4.8.2 regression] Used variant fun names in dwarf
info for CTORs
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chihin.ko at oracle dot com

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

for attached *.cc, there are 3 A CTORS and 3 variant A CTORS:

 nm a.out | grep _ZN1AC
00400a8c W _ZN1AC1Ei
00400ab2 W _ZN1AC1Eifci
00400a5a W _ZN1AC1Ev
00400a8c W _ZN1AC2Ei
00400ab2 W _ZN1AC2Eifci
00400a5a W _ZN1AC2Ev

In dwarf dump, _ZN1AC2... was used :

 grep _ZN1AC a.out.dw
  DW_AT_MIPS_linkage_name "_ZN1AC2Ev"
  DW_AT_MIPS_linkage_name "_ZN1AC2Ei"
  DW_AT_MIPS_linkage_name "_ZN1AC2Eifci"
name at offset 0x011a, length9 is '_ZN1AC2Ei'
name at offset 0x0143, length   12 is '_ZN1AC2Eifci'
name at offset 0x015a, length9 is '_ZN1AC2Ev'

I don't see _ZN1AC1... were used in a.out.dw

[Bug debug/65821] [4.8.2 regression] incorrect debug line # info for main

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
It is doing (b+3) first which is from :5 which seems correct to me.  Default
arguments should have a line information right?

[Bug debug/65821] [4.8.2 regression] incorrect debug line # info for main

[chihin.ko at oracle dot com]

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

--- Comment #2 from chihin ko  ---
(In reply to Andrew Pinski from comment #1)
> It is doing (b+3) first which is from :5 which seems correct to me.  Default
> arguments should have a line information right?

Then gdb should stop at line 30 first and when I step into foo(),
it stop at line 5. line 5 should belongs to foo().

Current behavior is confusing to user.