[Bug lto/79042] LTO doesn't propagate node->dynamically_initialized bit for varpool nodes.

[chefmax at gcc dot gnu.org]

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

--- Comment #4 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Jan 12 07:44:17 2017
New Revision: 244347

URL: https://gcc.gnu.org/viewcvs?rev=244347=gcc=rev
Log:
PR lto/79042
* lto-cgraph.c (lto_output_varpool_node): Pack dynamically_initialized
bit.
(input_varpool_node): Unpack dynamically_initialized bit.
* lto-streamer.h (LTO_minor_version): Bump version.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lto-cgraph.c
branches/gcc-5-branch/gcc/lto-streamer.h

[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used

[rschiele at gmail dot com]

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

--- Comment #5 from Robert Schiele  ---
Thanks! I can confirm that this also fixes the original problem for all cases
we observed so far.

[Bug tree-optimization/13563] if-conversion not agressive enough

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
With -Os, the jump2 pass does merge the 2 calls to foo, but that's way too late
for the resulting a!=0 ? 1 : 0 to be simplified.

[Bug testsuite/79067] New: gcc.dg/tree-prof/cold_partition_label.c runs a million times longer than it used to and times out

[sandra at gcc dot gnu.org]

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

Bug ID: 79067
   Summary: gcc.dg/tree-prof/cold_partition_label.c runs a million
times longer than it used to and times out
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

The change committed as part of r238325 made
gcc.dg/tree-prof/cold_partition_label.c run 100 times as long as it used
to, causing a timeout on a slow embedded target (nios2-linux-gnu):

Index: gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c
===
--- gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c   (revision
238324)
+++ gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c   (revision
238325)
@@ -29,9 +29,11 @@ foo (int path)
 int
 main (int argc, char *argv[])
 {
+  int i;
   buf_hot =  "hello";
   buf_cold = "world";
-  foo (argc);
+  for (i = 0; i < 100; i++)
+foo (argc);
   return 0;
 }

Other tests modified in the same commit have similar changes.

I did some experiments with different loop counts, measuring the total clock
time to run the one test as reported by the test harness:

   1000:12
  1:19
 10   1:32
100   timed out after 5:11

I'm not sure how to fix this.  I looked at the discussion on the mailing list
about the patch that caused the regression and saw a comment that, even with
the high counts, these tests don't run long enough to get good auto-fdo results
on the targets that support that feature, so cutting down the count across the
board doesn't seem like a good idea.  Nor does simply bumping up
dg-timeout-factor across the board-- why waste 10+ minutes running this test on
a slow target like nios2-linux-gnu that doesn't even support the auto-fdo
feature it's trying to test?  Maybe add something to target-supports.exp to
test for the presence of fdo support and use it to either skip the tests or
control a -D option on the command-line to set the number of iterations?

[Bug target/79066] New: [7 Regression] non-PIC code generated for powerpc glibc with -fpic

[jsm28 at gcc dot gnu.org]

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

Bug ID: 79066
   Summary: [7 Regression] non-PIC code generated for powerpc
glibc with -fpic
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-linux-gnu

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

GCC, configured thus for 32-bit powerpc hard-float, produces non-PIC code when
building glibc libm.

Target: powerpc-glibc-linux-gnu
Configured with: /scratch/jmyers/glibc/many7/src/gcc/configure
--prefix=/scratch/jmyers/glibc/many7/install/compilers/powerpc-linux-gnu
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=powerpc-glibc-linux-gnu
--with-sysroot=/scratch/jmyers/glibc/many7/install/compilers/powerpc-linux-gnu/sysroot
--disable-multilib --enable-secureplt --disable-libsanitizer --disable-libssp
--with-gmp=/scratch/jmyers/glibc/many7/install/host-libraries
--with-mpfr=/scratch/jmyers/glibc/many7/install/host-libraries
--with-mpc=/scratch/jmyers/glibc/many7/install/host-libraries
--enable-languages=c,c++ --enable-shared --enable-threads
Thread model: posix
gcc version 7.0.0 20170112 (experimental) [trunk revision 244346] (GCC) 

Compile with:

powerpc-glibc-linux-gnu-gcc -S -std=gnu11 -fgnu89-inline  -O2
-fmerge-all-constants -fno-stack-protector -frounding-math -fpic e_asin.i

The resulting code contains, towards the end of __ieee754_asin (and again for
__ieee754_acos):

lis 9,.LC44@ha
[...]
la 9,.LC44@l(9)

These are absolute non-PIC relocations and result in text relocations in
libm.so.

This appeared with r242908 but presumably was latent before then.

Preprocessed source attached.

[Bug c/79065] ARM generates ldm/stm on packed structs with aligned members

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
__attribute__((aligned(4)))

This causes the whole struct to become 4 byte aligned.

[Bug c/79065] ARM generates ldm/stm on packed structs with aligned members

[vielster at zee dot aero]

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

--- Comment #1 from Brian Viele  ---
gcc version 5.4.1 20160609 (release) [ARM/embedded-5-branch revision 237715]
(GCC) 

System: Linux xxx 4.4.0-47-generic #68~14.04.1-Ubuntu SMP Wed Oct 26 19:42:11
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[Bug c/79065] New: ARM generates ldm/stm on packed structs with aligned members

[vielster at zee dot aero]

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

Bug ID: 79065
   Summary: ARM generates ldm/stm on packed structs with aligned
members
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vielster at zee dot aero
  Target Milestone: ---

LDM/STM do not support unaligned access, so packed structs should not be
accessed in this way. If internal members of the struct are aligned to pad for
inter-platform compatibility (in this case, variable enum size), GCC generates
LDM/STM and can cause unaligned access faults.

Below is the code and the assembly generated with arm-none-eabi-gcc -O1

#include 
typedef struct __attribute__((__packed__))
{
  uint32_t a;
  uint8_t b __attribute__((aligned(4)));
  uint8_t c; 
}foo_t;

void struct_copy(foo_t *p_dest, foo_t *p_src)
{
  *p_src = *p_dest;
}

struct_copy(foo_t*, foo_t*):
mov r3, r1
ldmia   r0, {r0, r1}
stmia   r3, {r0, r1}
bx  lr

[Bug c++/14379] accepts invalid duplicate definition of member template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||7.0

--- Comment #5 from Martin Sebor  ---
The invalid test cases from comment #2 and comment #3 are still accepted by the
top of trunk (GCC 7.0).

[Bug middle-end/14236] VLA breaks alloca()

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||7.0
 Resolution|--- |DUPLICATE

--- Comment #11 from Martin Sebor  ---
The attached test case passes with  today's top of trunk (GCC 7.0).  I believe
the underlying problem was fixed and the manual updated in r227860 committed to
resolve bug 65958.

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

[Bug middle-end/65958] -fstack-check breaks alloca on architectures using generic stack checking

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #10 from Martin Sebor  ---
*** Bug 14236 has been marked as a duplicate of this bug. ***

[Bug c/14030] missing parameter count check ?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail|3.3.3, 3.4.0|4.5.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.3.0, 7.0

--- Comment #5 from Martin Sebor  ---
Output with today's top of trunk shows no progress has been made.  Clang
diagnoses it by issuing warnings similar to ICC's.

$ cat t.c && gcc -S -Wall -Wextra -Wpedantic t.c
void f (one, two)
  int one;
  char two;
{ }

void g(int i)
{
  f (1);
  f (1, 'e', i);
}
t.c: In function ‘f’:
t.c:2:7: warning: unused parameter ‘one’ [-Wunused-parameter]
   int one;
   ^~~
t.c:3:8: warning: unused parameter ‘two’ [-Wunused-parameter]
   char two;
^~~

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||7.0

--- Comment #11 from Martin Sebor  ---
The errors printed by today's top of trunk (GCC 7.0) for the test case from
comment #9 are below.  They seem quite clear, at least as good as if not better
than Clang's which prints those below.  Resolving as fixed.

error: no matching function for call to 'foo'
int i = foo( (B*)0 );
^~~
note: candidate function not viable: no known conversion from 'B *' to 'B *&'
for 1st argument


$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C

struct B {}; 
struct D : B {}; 

struct X {};

int foo(B*&);

int i = foo( (B*)0 );

int j = foo( (D*)0 );

D* pd = 0;
int k = foo( pd );

X* px = 0;
int l = foo( px );\
t.C:17:19: warning: backslash-newline at end of file
 int l = foo( px );\

t.C:9:20: error: cannot bind non-const lvalue reference of type ‘B*&’ to an
rvalue of type ‘B*’
 int i = foo( (B*)0 );
^
t.C:7:5: note:   initializing argument 1 of ‘int foo(B*&)’
 int foo(B*&);
 ^~~
t.C:11:20: error: cannot bind non-const lvalue reference of type ‘B*&’ to an
rvalue of type ‘B*’
 int j = foo( (D*)0 );
^
t.C:7:5: note:   initializing argument 1 of ‘int foo(B*&)’
 int foo(B*&);
 ^~~
t.C:14:17: error: cannot bind non-const lvalue reference of type ‘B*&’ to an
rvalue of type ‘B*’
 int k = foo( pd );
 ^
t.C:7:5: note:   initializing argument 1 of ‘int foo(B*&)’
 int foo(B*&);
 ^~~
t.C:17:17: error: invalid initialization of reference of type ‘B*&’ from
expression of type ‘X*’
 int l = foo( px );\
 ^
t.C:7:5: note: in passing argument 1 of ‘int foo(B*&)’
 int foo(B*&);
 ^~~

[Bug c++/16992] [meta-bug] -fpermissive causes some diagnostic problems

[msebor at gcc dot gnu.org]

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

Bug 13979 Summary: Error message about no matching function for call with 
derived class arguments could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13979

   What|Removed |Added

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

[Bug target/72749] [7 Regression] ICE: verify_flow_info failed (error: wrong amount of branch edges after conditional jump in bb 5) w/ -O2 -fsched2-use-superblocks

[amodra at gmail dot com]

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

--- Comment #6 from Alan Modra  ---
OK, currently testing TARGET_LEGITIMATE_COMBINED_INSN solution.  Thanks for the
analysis!

[Bug tree-optimization/13563] if-conversion not agressive enough

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0, 7.0

--- Comment #3 from Martin Sebor  ---
No progress in GCC 7.0:

$ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wshadow
-fdump-tree-optimized=/dev/stdout -o/dev/stdout  t.c

void foo (int);

void bar (int a)
{
  if (a)
foo (1);
  else
foo (0);
}

void baz (int a)
{
  foo (!!a);
}
.file   "t.c"

;; Function bar (bar, funcdef_no=0, decl_uid=1797, cgraph_uid=0,
symbol_order=0)

bar (int a)
{
   [100.00%]:
  if (a_2(D) != 0)
goto ; [46.00%]
  else
goto ; [54.00%]

   [46.00%]:
  foo (1); [tail call]
  goto ; [100.00%]

   [54.00%]:
  foo (0); [tail call]

   [100.00%]:
  return;

}


.text
.p2align 4,,15
.globl  bar
.type   bar, @function
bar:
.LFB0:
.cfi_startproc
testl   %edi, %edi
jne .L4
xorl%edi, %edi
jmp foo
.p2align 4,,10
.p2align 3
.L4:
movl$1, %edi
jmp foo
.cfi_endproc
.LFE0:
.size   bar, .-bar

;; Function baz (baz, funcdef_no=1, decl_uid=1800, cgraph_uid=1,
symbol_order=1)

baz (int a)
{
  _Bool _1;
  int _2;

   [100.00%]:
  _1 = a_3(D) != 0;
  _2 = (int) _1;
  foo (_2); [tail call]
  return;

}


.p2align 4,,15
.globl  baz
.type   baz, @function
baz:
.LFB1:
.cfi_startproc
testl   %edi, %edi
setne   %dil
movzbl  %dil, %edi
jmp foo
.cfi_endproc
.LFE1:
.size   baz, .-baz
.ident  "GCC: (GNU) 7.0.0 20170110 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug c++/13452] No error on invalid CV qualifier on member function returning function pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2005-12-18 20:25:19 |2017-1-11
 CC||msebor at gcc dot gnu.org
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0, 7.0

--- Comment #7 from Martin Sebor  ---
The invalid test case from comment #0 is still accepted by the top of trunk
(GCC 7.0).  Both Clang and Oracle Solaris Studio reject the program with a
similar error:

"t.C", line 1: Error: Non-member function pointer cannot point to a const
function.

[Bug rtl-optimization/13355] Suboptimal code generated with global register variables

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Martin Sebor  ---
Wiuth today's top of trunk (GCC 7.0) the object code below matches closely the
assembly expected in comment #3.  Resolving as fixed.

op_imull_EAX_T0:
.LFB1:
.cfi_startproc
movl%ebx, %eax
imull   0(%ebp)
movl%edx, %ecx
movl%eax, %edx
movl%eax, 0(%ebp)
movl%edx, %eax
cltd
xorl%eax, %eax
cmpl%ecx, %edx
setne   %al
movl%ecx, 8(%ebp)
movl%eax, 32(%ebp)
ret

[Bug rtl-optimization/13214] GCJ uses surprsingly long to compile included example

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #6 from Martin Sebor  ---
Gcj has been removed from GCC in the 7.0 cycle.  Closing as Won't Fix.

[Bug c++/13166] [DR136] not implemented

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0, 7.0

--- Comment #8 from Martin Sebor  ---
GCc 7.0 still accepts the small test case from comment #2.  Clang rejects it
with:

t.C:4:13: error: friend declaration specifying a default argument must be a
  definition
friend int compare_unsigned(int if_v_signed = 0);
   ^
1 error generated.

[Bug c++/13005] Pointer adjusted for derived class containing virtual function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Priority|P2  |P3
 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #38 from Martin Sebor  ---
I don't see any spurious instructions in the unoptimized x86 assembly emitted
ny current trunk of 7.0 for the test case from comment #0 (below).

Running the program attached in comment #4 does still output the following:

  *** Last forward pointer should be list header.
  *** Backward: 1: is 0x602130 should be 0x602160

But given the lack of progress or any indication of activity on this bug in
over a decade, should it be closed as Won't Fix?  In the meantime, lowering
priority to P3.

_ZN4Base11insertAfterEP7Derived:
.LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
movl8(%ebp), %eax
movl(%eax), %eax
movl12(%ebp), %edx
movl%edx, 8(%eax)
nop
popl%ebp

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to hs.naveen2u from comment #2)
> Could not reproduce the issue on latest FSF source:-
> 
> Tried using the following command:-
> -gcc -fstack-check gcc/testsuite/gcc.target/aarch64/stack-checking.c 
> -mabi=ilp32

I can though:
FAIL: gcc.target/aarch64/stack-checking.c (internal compiler error)
FAIL: gcc.target/aarch64/stack-checking.c (test for excess errors)

[Bug c++/12697] Redundant duplicate error message

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||7.0
 Resolution|--- |FIXED
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0

--- Comment #10 from Martin Sebor  ---
Today's top of trunk (GCC 7) prints the following single error message followed
by four distinct notes.  There is no duplication there (6.3 still prints a
duplicate message).  Resolving as fixed.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
void Foo(signed char, signed char);
void Foo(unsigned char, unsigned char);

void Foo(int, int);
void Foo(unsigned int, unsigned int);

int main() {
  unsigned char u;
  signed char i;
  Foo(u, i);
}
t.C: In function ‘int main()’:
t.C:10:11: error: call of overloaded ‘Foo(unsigned char&, signed char&)’ is
ambiguous
   Foo(u, i);
   ^
t.C:1:6: note: candidate: void Foo(signed char, signed char)
 void Foo(signed char, signed char);
  ^~~
t.C:2:6: note: candidate: void Foo(unsigned char, unsigned char)
 void Foo(unsigned char, unsigned char);
  ^~~
t.C:4:6: note: candidate: void Foo(int, int)
 void Foo(int, int);
  ^~~
t.C:5:6: note: candidate: void Foo(unsigned int, unsigned int)
 void Foo(unsigned int, unsigned int);

[Bug c++/12672] Evals template defaults args that it should not

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0, 7.0

--- Comment #14 from Martin Sebor  ---
With today's top of trunk (GCC 7) the error for the test case from comment #4
is still the same.  Other compilers, including Clang 3.8, EDG 4.11, IBM XLC++,
and Microsoft Visual Studio successfully compile the code.

[Bug c++/12333] [DR 272] Explicit call to MyClass::~MyClass() not allowed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0, 7.0

--- Comment #16 from Martin Sebor  ---
Today's top of trunk (GCC 7.0) still fails.  Other compilers, including Clang
and Oracle Solaris Studio, accept the code.

$ cat t.C && gcc -O2 -S -Wall -Wextra t.C
struct X { 
  void f () { 
X::~X ();  
  }  
};  
t.C: In member function ‘void X::f()’:
t.C:3:12: error: no matching function for call to ‘X::X()’
 X::~X ();
^
t.C:1:8: note: candidate: X::~X()
 struct X {
^
t.C:1:8: note:   candidate expects 1 argument, 0 provided

[Bug c++/12277] eliminate and warn on dynamic casts with known NULL results

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P2  |P3
   Last reconfirmed|2006-02-26 19:21:22 |2017-1-11
 CC||msebor at gcc dot gnu.org
Summary|Warn on dynamic casts with  |eliminate and warn on
   |known NULL results. |dynamic casts with known
   ||NULL results
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0, 7.0

--- Comment #10 from Martin Sebor  ---
Besides warning, GCC could also optimize the dynamic_cast away when it's known
to fail.  The GCC 7.0 dump below for a slightly modified version of the test
case from comment #3 shows that it does neither.  At the same time, since this
is a rare case, I don't think it justifies P2.  Lowering to P3.

$ gcc$ cat t.C && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
t.C
struct Base { virtual ~Base () {} }; 
class Derived : Base { friend int main (); }; 

int main () 
{ 
  Base *p = new Derived; 

  if (dynamic_cast(p) != 0)
  __builtin_abort ();
} 

...

;; Function int main() (main, funcdef_no=4, decl_uid=2303, cgraph_uid=10,
symbol_order=10) (executed once)

int main() ()
{
  void * _1;
  void * _4;

   [100.00%]:
  _4 = operator new (8);
  MEM[(struct Derived *)_4].D.2316._vptr.Base = [(void *)&_ZTV7Derived +
16B];
  _1 = __dynamic_cast (_4, &_ZTI4Base, &_ZTI7Derived, -2);
  if (_1 != 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin_abort ();

   [99.96%]:
  return 0;

}

[Bug c++/78337] "internal compiler error: Segmentation fault", using local variable in lambda return-type deduction

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Jan 11 21:43:42 2017
New Revision: 244340

URL: https://gcc.gnu.org/viewcvs?rev=244340=gcc=rev
Log:
PR c++/78337 - ICE on invalid with generic lambda

* semantics.c (process_outer_var_ref): Check if containing_function
is null.  Move inform call under complain test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug tree-optimization/71237] [7 regression] scev tests failing after pass reorganization

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #8 from sandra at gcc dot gnu.org ---
This is still failing on nios2-linux-gnu.

[Bug c++/24511] [DR 470] explicit instantiation/extern template unsats on symbols defined later

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.0
 Resolution|--- |FIXED
  Known to fail||

--- Comment #10 from Martin Sebor  ---
This works with GCC 7.0, and possibly prior.  It may have been fixed as a
result of the related bug 22263.

[Bug c++/24511] [DR 470] explicit instantiation/extern template unsats on symbols defined later

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
Author: msebor
Date: Wed Jan 11 21:02:46 2017
New Revision: 244337

URL: https://gcc.gnu.org/viewcvs?rev=244337=gcc=rev
Log:
PR c++/24511 - [DR 470] explicit instantiation/extern template unsats
// on symbols defined later

gcc/testsuite/ChangeLog:
* g++.dg/template/explicit9.C: New test.

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

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I'll take a look.

[Bug c++/77812] [5/6/7 Regression] incorrectly rejects valid C++ code that uses enum in template instantiation

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
Author: nathan
Date: Wed Jan 11 20:49:50 2017
New Revision: 244336

URL: https://gcc.gnu.org/viewcvs?rev=244336=gcc=rev
Log:
cp/
PR c++/77812
* name-lookup.c (set_namespace_binding_1): An overload of 1 decl
is a new overload.

testsuite/
PR c++/77812
* g++.dg/pr77812.C: New.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr77812.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/name-lookup.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/12228] [DR 244/399] syntax error calling a qualified template dtor

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2005-12-18 20:16:40 |2017-1-11
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0, 7.0

--- Comment #4 from Martin Sebor  ---
Today's top of trunk (GCC 7.0) fails with the errors below.  Clang also fails
to compile it but EDG eccp, IBM XLC++, and Oracle Studio 12.4 all accept the
code.

t.C: In function ‘void foo(N::B*)’:
t.C:17:20: error: expected ‘;’ before ‘::’ token
 /*  17 */ p->NB::~NB ();
^~
t.C: In function ‘void foo(typename N::B::BT*)’:
t.C:24:20: error: expected ‘;’ before ‘::’ token
 /*  24 */ p->BT::~BT ();
^~
t.C: In function ‘void foo(N::C*)’:
t.C:31:20: error: expected ‘;’ before ‘::’ token
 /*  31 */ p->NC::~NC ();
^~
t.C: In function ‘void foo(typename N::C::CA*)’:
t.C:38:20: error: expected ‘;’ before ‘::’ token
 /*  38 */ p->CA::~CA ();
^~

[Bug testsuite/12096] dejagnu truncates output from spawned commands randomly, causing intermittant failed tests

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #15 from Martin Sebor  ---
I haven't seen this problem although I have reported intermittent test failures
in parallel builds in bug 77684.  Since the recommended DejaGnu, Expect, and
Tcl versions are documented on the GCC Prerequisites page
(https://gcc.gnu.org/install/prerequisites.html) and since there has been no
progress or activity on this bug in a decade I'll close it as Works For Some. 
If it persists or if the documentation is still inaccurate or insufficient
please either reopen this bug or open a new one and attach the relevant output
and version information or explain how the documentation should change.

[Bug c++/77812] [5/6/7 Regression] incorrectly rejects valid C++ code that uses enum in template instantiation

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Wed Jan 11 20:37:16 2017
New Revision: 244335

URL: https://gcc.gnu.org/viewcvs?rev=244335=gcc=rev
Log:
cp/
PR c++/77812
* name-lookup.c (set_namespace_binding_1): An overload of 1 decl
is a new overload.

testsuite/
PR c++/77812
* g++.dg/pr77812.C: New.

Added:
trunk/gcc/testsuite/g++.dg/pr77812.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/72813] [6 Regression] atomic header cannot be compiled into translation unit with -fkeep-inline-functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] atomic |[6 Regression] atomic
   |header cannot be compiled   |header cannot be compiled
   |into translation unit with  |into translation unit with
   |-fkeep-inline-functions |-fkeep-inline-functions

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug c++/78341] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_parser_std_attribute_spec, at cp/parser.c:24597)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/55004] [meta-bug] constexpr issues

[jakub at gcc dot gnu.org]

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

Bug 71537 Summary: GCC rejects consetxpr boolean conversions and comparisons on 
the result of pointer arithmetic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537

   What|Removed |Added

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

[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #16 from Martin Sebor  ---
See also bug 78257 for a related enhancement.

[Bug tree-optimization/78257] missing memcmp optimization with constant arrays

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=12086

--- Comment #6 from Martin Sebor  ---
See also bug 12086 for a related enhancement to memcmp.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
When a fix exists, why hasn't it been posted to gcc-patches?

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 11 20:10:36 2017
New Revision: 244333

URL: https://gcc.gnu.org/viewcvs?rev=244333=gcc=rev
Log:
PR c++/71537
* fold-const.c (maybe_nonzero_address): Return 1 for function
local objects.
(tree_single_nonzero_warnv_p): Don't handle function local objects
here.

* g++.dg/cpp1y/constexpr-71537.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-71537.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/11858] Name lookup error ignored when instantiated from expression within sizeof() in template function parameter

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2012-10-10 00:00:00 |2017-1-11
 CC||msebor at gcc dot gnu.org
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0, 7.0

--- Comment #10 from Martin Sebor  ---
The invalid test case is still accepted by current trunk of GCC 7.0.

[Bug c++/20308] parser thinks something is a start of a template-id when it is just less than

[msebor at gcc dot gnu.org]

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

Bug 11814 Summary: Code with missing "template" keyword wrongly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11814

   What|Removed |Added

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

[Bug c++/12944] [meta-bug] C++ name-lookup problems

[msebor at gcc dot gnu.org]

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

Bug 11814 Summary: Code with missing "template" keyword wrongly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11814

   What|Removed |Added

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

[Bug c++/11814] Code with missing "template" keyword wrongly accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||7.0
 Resolution|--- |FIXED
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0

--- Comment #16 from Martin Sebor  ---
With the current trunk of GCC 7.0 the test cases are rejected as expected (GCC
6 still accepts it).  Closing as fixed.

$ cat t.C && gcc -O2 -S -Wall -Wextra t.C
template  struct A
{
template  void foo();
};

template  struct B
{
template  void foo()
{
A* p;
p->foo(); // wrong: should be "p->template foo();"
}
};
t.C: In member function ‘void B::foo()’:
t.C:11:16: error: expected primary-expression before ‘int’
 p->foo(); // wrong: should be "p->template foo();"
^~~
t.C:11:16: error: expected ‘;’ before ‘int’

[Bug c++/6023] Unhelpful error message with forgotten "template"

[msebor at gcc dot gnu.org]

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

Bug 11814 Summary: Code with missing "template" keyword wrongly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11814

   What|Removed |Added

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

[Bug bootstrap/11776] configure from path with spaces does not work

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Sebor  ---
Many UNIX scripts don't work correctly with pathnames containing spaces. 
That's why the POSIX standard recommends portable applications to limit the
characters in file names to the Portable Filename Character Set which consists
of alphanumeric characters plus the period, hyphen, and underscore.  To avoid
problems, configure in a directory that doesn't contain spaces.  Closing as
Won't Fix.

[Bug c++/11582] Odd error message with dynamically sized template arg printing

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Priority|P2  |P3
 CC||msebor at gcc dot gnu.org
   Severity|normal  |minor

--- Comment #11 from Martin Sebor  ---
Today's trunk of GCC 7 prints the following.  Since there doesn't appear to be
a "correct" way to print the function signature (although several attempts seem
to have been made none has been found since 2003), if the bug is to stay open,
I think its priority and importance should be lower.  Setting P3 and Minor.

t.C: In function ‘void g()’:
t.C:6:10: error: no matching function for call to ‘f(int [( + 1)])’
   f( buf ) ;
  ^
t.C:2:28: note: candidate: template void f(int (&)[N])
 template   void f(int (&)[N]);
^
t.C:2:28: note:   template argument deduction/substitution failed:
t.C:6:10: note:   variable-sized array type ‘long int’ is not a valid template
argument
   f( buf ) ;
  ^

The messages printed by some other compilers are below for reference. 
Personally, I think the Visual Studio error looks quite good.

Clang 3.8:
t.C:6:3: error: no matching function for call to 'f'
  f( buf ) ; 
  ^
t.C:2:28: note: candidate template ignored: could not match 'int' against 'int'
template   void f(int (&)[N]); 
   ^

IBM XLC++:
"t.C", line 2.28: 1540-1173 (S) "int (&)[]" is not a valid parameter type.
"t.C", line 6.3: 1540-0700 (I) The previous message was produced while
processing "f<0>".

Intel ICC 17:
error: no instance of function template "f" matches the argument list
note: this candidate was rejected because at least one template argument could
not be deduced

Microsoft Visual Studio:
error C2672: 'f': no matching overloaded function found
source_file.cpp(6): error C2784: 'void f(int (&)[N])': could not deduce
template argument for 'int (&)[N]' from 'int ['function']'
source_file.cpp(2): note: see declaration of 'f'

Oracle Solaris Studio 12.4:
"t.C", line 5: Error: An integer constant expression is required within the
array subscript operator.

[Bug c++/79064] New: Cannot overload member function templates on type of literal

[hstong at ca dot ibm.com]

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

Bug ID: 79064
   Summary: Cannot overload member function templates on type of
literal
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

In the case below, the signatures of the two member templates are distinct.
GCC appears to have a problem recognizing that the types of 1 and 1ll differ.
Neither Clang nor MSVC appears to have this issue.

### Source ():
struct A {
  template 
  void f(char (*)[0u - 1 > (M - M) ? 42 : 47]);
  template 
  void f(char (*)[0u - 1ll > (M - M) ? 42 : 47]);
};

void f(A a) {
  char x[42], y[47];
  a.f<0>();
  a.f<0>();
}


### Compile command:
g++ -c -o a.o -x c++ -


### Actual output:
:5:8: error: 'template void A::f(char (*)[(((0 - 1) > (M
- M)) ? 42 : 47)])' cannot be overloaded
:3:8: error: with 'template void A::f(char (*)[(((0 - 1)
> (M - M)) ? 42 : 47)])'
: In function 'void f(A)':
:11:12: error: no matching function for call to 'A::f<0>(char (*)[47])'
:3:8: note: candidate: template void A::f(char (*)[(((0
- 1) > (M - M)) ? 42 : 47)])
:3:8: note:   template argument deduction/substitution failed:
:11:10: note:   cannot convert '& y' (type 'char (*)[47]') to type 'char
(*)[42]'


### Expected output:
(Clean compile)


### g++ -v:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-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 7.0.0 20161219 (experimental) (GCC)

[Bug c++/11187] signed/unsigned conversion behaves differently

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2012-01-13 00:00:00 |2017-1-11
 CC||msebor at gcc dot gnu.org
  Known to fail||3.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.3.0, 7.0

--- Comment #3 from Martin Sebor  ---
The signed case is still accepted by today's trunk.  Clang diagnoses both as
expected.

$ (set -x && cat t.c && for s in signed unsigned; do gcc -DSIGN=$s -S -Wall
-xc++ t.c; done)
+ cat t.c
class Object
{
 SIGN short value;
public:
 operator SIGN short() { return value; }
 operator SIGN int()   { return value; }
};

SIGN int test(void)
{
 Object a,b;
 return a+b;
}
+ for s in signed unsigned
+ gcc -DSIGN=signed -S -Wall -xc++ t.c
+ for s in signed unsigned
+ gcc -DSIGN=unsigned -S -Wall -xc++ t.c
t.c: In function ‘unsigned int test()’:
t.c:12:10: error: ambiguous overload for ‘operator+’ (operand types are
‘Object’ and ‘Object’)
  return a+b;
 ~^~
t.c:12:10: note: candidate: operator+(int, int) 
t.c:12:10: note: candidate: operator+(int, unsigned int) 
t.c:12:10: note: candidate: operator+(unsigned int, int) 
t.c:12:10: note: candidate: operator+(unsigned int, unsigned int) 

[Bug rtl-optimization/79059] Information from CCmode is not propagated across basic blocks

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
I can't remember if this is the same but 

I don't know how to describe this optimization right now but take the following
two functions:
struct arc
{
  int ident;
};
int bea_is_dual_infeasible( struct arc *arc, int red_cost )
{
return( (red_cost < 0 && arc->ident == 1)
|| (red_cost > 0 && arc->ident == 2) );
}

int bea_is_dual_infeasible1( struct arc *arc, int red_cost )
{
  int t;
  if (red_cost == 0)
return 0;
  return arc->ident == ((red_cost > 0) ? 2 : 1);
}
They both do the same thing but bea_is_dual_infeasible1 has only one branch (no
conditional move either) while bea_is_dual_infeasible has many branches.  This
is true on x86 (have not checked arm though).

[Bug bootstrap/79063] GCC Master fails to build for sh

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
Duplicate.

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

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||joel at gcc dot gnu.org

--- Comment #15 from Joseph S. Myers  ---
*** Bug 79063 has been marked as a duplicate of this bug. ***

[Bug c/47931] missing -Waddress warning for comparison with NULL

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Martin Sebor  ---
This seems to have been implemented since GCC 4.6.  In fact, I just found the
change that added it: r158765 committed to fix bug 32207 that this is a dupe
of.

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

[Bug c/32207] missing warnings about address of 'x'.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
*** Bug 47931 has been marked as a duplicate of this bug. ***

[Bug c/47931] missing -Waddress warning for comparison with NULL

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Wed Jan 11 18:33:13 2017
New Revision: 244331

URL: https://gcc.gnu.org/viewcvs?rev=244331=gcc=rev
Log:
PR c/47931 - missing -Waddress warning for comparison with NULL

gcc/testsuite/ChangeLog:
* c-c++-common/Waddress-2.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/Waddress-2.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/78341] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: in cp_parser_std_attribute_spec, at cp/parser.c:24597)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 11 18:09:58 2017
New Revision: 244329

URL: https://gcc.gnu.org/viewcvs?rev=244329=gcc=rev
Log:
PR c++/78341
* parser.c (cp_parser_std_attribute_spec): Remove over-eager
assertion.  Formatting fix.

* g++.dg/cpp0x/pr78341.C: New test.

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

[Bug c++/72813] [6/7 Regression] atomic header cannot be compiled into translation unit with -fkeep-inline-functions

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 11 18:08:57 2017
New Revision: 244328

URL: https://gcc.gnu.org/viewcvs?rev=244328=gcc=rev
Log:
PR c++/72813
* gcc.c (default_compilers): Don't add -o %g.s for -S -save-temps
of c-header.

* c-decl.c (pop_file_scope): Set flag_syntax_only to 1 after writing
PCH file.

* decl2.c (c_parse_final_cleanups): Set flag_syntax_only to 1 after
writing PCH file.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/gcc.c

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-11
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Jakub Jelinek  ---
Created attachment 40505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40505=edit
gcc7-pr78839.patch

There were actually numerous bugs in that commit in the field_byte_offset
routine.  is_bit_offset_cst and is_byte_offset_cst vars were set to values that
is the opposite of their names, then the whole PCC_BITFIELD_TYPE_MATTERS block
was actually never entered, because there was:
  if (is_bit_offset_cst)
return NULL;

#ifdef PCC_BITFIELD_TYPE_MATTERS
  /* We used to handle only constant offsets in all cases.  Now, we handle
 properly dynamic byte offsets only when PCC bitfield type doesn't
 matter.  */
  if (PCC_BITFIELD_TYPE_MATTERS && is_byte_offset_cst && is_bit_offset_cst)

and after the first if is_bit_offset_cst thus was always false.  But even with
that fixed, the whole block computed something that has been just ignored.

So, let's fix this first, then as incremental separately tested patch also use
DECL_BIT_FIELD_REPRESENTATIVE if possible, and lastly for DWARF-4 and later we
actually shouldn't be emitting for bitfields DW_AT_data_member_location and
DW_AT_byte_size and DW_AT_bit_offset attributes at all, we should emit
DW_AT_data_bit_offset (PR71669) instead of those.  As GDB just gained
DW_AT_data_bit_offset support last November, I'll for now use it only for
-gdwarf-5 (which requires latest GDB anyway).

[Bug c/72783] Fortify scanf %s, %[ conversion specifiers

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
I've run out of time to implement this in GCC 7 but I'll see about handling it
in GCC 8.

[Bug middle-end/77708] -Wformat-length %s warns for snprintf

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
*** Bug 77675 has been marked as a duplicate of this bug. ***

[Bug c/77675] optimization level==number of -Wformat-length warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Sebor  ---
This seems to have been fixed as a result of introducing -Wformat-truncation in
r244210.  Resolving as a duplicate of 77708.

For the record, here's the output at the default setting of the -Wformat-length
and -Wformat-truncation options with today's top of trunk:

$ (set -x; for o in 0 1 2; do gcc -O$o -S -Wformat -Wformat-length
-Wformat-truncation algapi.i; done)
+ for o in 0 1 2
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O0 -S -Wformat -Wformat-length
-Wformat-truncation algapi.i
+ for o in 0 1 2
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O1 -S -Wformat -Wformat-length
-Wformat-truncation algapi.i
+ for o in 0 1 2
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -S -Wformat -Wformat-length
-Wformat-truncation algapi.i

And here's the output at level 2:

$ (set -x; for o in 0 1 2 3; do gcc -O$o -S -Wformat -Wformat-length=2
-Wformat-truncation=2 algapi.i; done)
+ for o in 0 1 2 3
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O0 -S -Wformat
-Wformat-length=2 -Wformat-truncation=2 algapi.i
crypto/algapi.c: In function ‘crypto_inst_setname’:
crypto/algapi.c:817:6: warning: ‘%s’ directive output may be truncated writing
between 1 and 63 bytes into a region of size 62 [-Wformat-truncation=]
crypto/algapi.c:817:6: note: format output between 5 and 67 bytes into a
destination of size 64
+ for o in 0 1 2 3
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O1 -S -Wformat
-Wformat-length=2 -Wformat-truncation=2 algapi.i
crypto/algapi.c: In function ‘crypto_inst_setname’:
crypto/algapi.c:817:6: warning: ‘%s’ directive output may be truncated writing
between 1 and 63 bytes into a region of size 62 [-Wformat-truncation=]
crypto/algapi.c:817:6: note: format output between 5 and 67 bytes into a
destination of size 64
+ for o in 0 1 2 3
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -S -Wformat
-Wformat-length=2 -Wformat-truncation=2 algapi.i
crypto/algapi.c: In function ‘crypto_inst_setname’:
crypto/algapi.c:817:6: warning: ‘%s’ directive output may be truncated writing
between 1 and 63 bytes into a region of size 62 [-Wformat-truncation=]
crypto/algapi.c:817:6: note: format output between 5 and 67 bytes into a
destination of size 64
crypto/algapi.c: In function ‘crypto_alloc_instance2’:
crypto/algapi.c:817:6: warning: ‘%s’ directive output may be truncated writing
between 1 and 63 bytes into a region of size 62 [-Wformat-truncation=]
crypto/algapi.c:817:6: note: format output between 5 and 67 bytes into a
destination of size 64
+ for o in 0 1 2 3
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O3 -S -Wformat
-Wformat-length=2 -Wformat-truncation=2 algapi.i
crypto/algapi.c: In function ‘crypto_inst_setname’:
crypto/algapi.c:817:6: warning: ‘%s’ directive output may be truncated writing
between 1 and 63 bytes into a region of size 62 [-Wformat-truncation=]
crypto/algapi.c:817:6: note: format output between 5 and 67 bytes into a
destination of size 64
crypto/algapi.c: In function ‘crypto_alloc_instance2’:
crypto/algapi.c:817:6: warning: ‘%s’ directive output may be truncated writing
between 1 and 63 bytes into a region of size 62 [-Wformat-truncation=]
crypto/algapi.c:817:6: note: format output between 5 and 67 bytes into a
destination of size 64
crypto/algapi.c: In function ‘crypto_alloc_instance’:
crypto/algapi.c:817:6: warning: ‘%s’ directive output may be truncated writing
between 1 and 63 bytes into a region of size 62 [-Wformat-truncation=]
crypto/algapi.c:817:6: note: format output between 5 and 67 bytes into a
destination of size 64

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

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
I am seeing the FAIL for the missing line 140 diagnostic on nios2-linux-gnu as
well.

[Bug bootstrap/79063] New: GCC Master fails to build for sh

[joel at gcc dot gnu.org]

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

Bug ID: 79063
   Summary: GCC Master fails to build for sh
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org
  Target Milestone: ---

7.0.0 20170111

Nothing particularly special about the build. Just fails early with ICE.

/home/joel/test-gcc/b-sh-elf-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-sh-elf-gcc/./gcc/ -nostdinc
-B/home/joel/test-gcc/b-sh-elf-gcc/sh-elf/newlib/ -isystem
/home/joel/test-gcc/b-sh-elf-gcc/sh-elf/newlib/targ-include -isystem
/home/joel/test-gcc/gcc/newlib/libc/include
-B/home/joel/test-gcc/b-sh-elf-gcc/sh-elf/libgloss/sh
-L/home/joel/test-gcc/b-sh-elf-gcc/sh-elf/libgloss/libnosys
-L/home/joel/test-gcc/gcc/libgloss/sh
-B/home/joel/test-gcc/install-master/sh-elf/bin/
-B/home/joel/test-gcc/install-master/sh-elf/lib/ -isystem
/home/joel/test-gcc/install-master/sh-elf/include -isystem
/home/joel/test-gcc/install-master/sh-elf/sys-include-g -O2 -ml -O2  -g -O2
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../gcc/libgcc
-I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc
-I../../../../gcc/libgcc/../include  -DHAVE_CC_TLS  -o _mul_df.o -MT _mul_df.o
-MD -MP -MF _mul_df.dep -DFINE_GRAINED_LIBRARIES -DL_mul_df  -c
../../../../gcc/libgcc/fp-bit.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc/libgcc/fp-bit.c: In function '__muldf3':
../../../../gcc/libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the
insn
 }
 ^
(insn 768 291 296 29 (set (reg:SI 147 t)
(eq:SI (and:SI (subreg:SI (reg/v:DI 205 [ high ]) 0)
(const_int 1 [0x1]))
(const_int 0 [0]))) "../../../../gcc/libgcc/fp-bit.c":881 -1
 (nil))
../../../../gcc/libgcc/fp-bit.c:944:1: error: shared rtx
(subreg:SI (reg/v:DI 205 [ high ]) 0)
../../../../gcc/libgcc/fp-bit.c:944:1: internal compiler error: internal
consistency failure
0x68b8c8 verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2774
0x68b7ef verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2789
0x68b7ef verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2789
0x68b7ef verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2789
0x68bbeb verify_insn_sharing
../../gcc/gcc/emit-rtl.c:2860
0x6900e7 verify_rtl_sharing()
../../gcc/gcc/emit-rtl.c:2883
0x920acb execute_function_todo
../../gcc/gcc/passes.c:1982
0x9214a5 execute_todo
../../gcc/gcc/passes.c:2015
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 rtl-optimization/79059] Information from CCmode is not propagated across basic blocks

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #4 from Andrew Pinski  ---
Iirc there is even better way of doing these branches that is arch independent.

[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
r244326 adds LTO to -Walloca-larger-than, -Wformat-length, and
-Wformat-truncation, making the -Walloca-larger-than warning work with LTO. 
Even though the gimple-ssa-sprintf pass seems to run with -flto the other two
warnings still don't work for some reason.  I've raised bug 79062 to track
that.

[Bug lto/79062] New: -Wformat-length warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

Bug ID: 79062
   Summary: -Wformat-length warnings disabled by -flto
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following enhanced test case shows that with r244326 committed to resolve
bug 78768, even though the gimple-ssa-sprintf pass seems to run with -flto,
-Wformat-length (and likely -Wformat-truncation) still doesn't work for some
reason.

$ (set -x; for o in '' '-flto'; do /build/gcc-svn/gcc/xgcc -B
/build/gcc-svn/gcc -O2 -Wall -Wextra -Wpedantic -Walloca-larger-than=1
-Wformat-length=1 $o -fpic -shared -o foo.so -fdump-tree-optimized t.c; cat
t.c.*.optimized; done)
+ for o in ''\'''\''' ''\''-flto'\'''
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -Wall -Wextra -Wpedantic
-Walloca-larger-than=1 -Wformat-length=1 -fpic -shared -o foo.so
-fdump-tree-optimized t.c
t.c: In function ‘f’:
t.c:3:9: warning: argument to ‘alloca’ is too large [-Walloca-larger-than=]
   char *d = (char *)__builtin_alloca (2);
 ^
t.c:3:9: note: limit is 1 bytes, but argument is 2
t.c:4:33: warning: ‘%i’ directive writing 3 bytes into a region of size 2
[-Wformat-length=]
   return __builtin_sprintf (d, "%i", 123);
 ^~
t.c:4:10: note: format output 4 bytes into a destination of size 2
   return __builtin_sprintf (d, "%i", 123);
  ^~~~
+ cat t.c.227t.optimized

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

f ()
{
  char * d;
  int _5;

   [100.00%]:
  d_3 = __builtin_alloca (2);
  _5 = __builtin_sprintf (d_3, "%i", 123);
  return _5;

}



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

g ()
{
   [100.00%]:
  return 3;

}


+ for o in ''\'''\''' ''\''-flto'\'''
+ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -Wall -Wextra -Wpedantic
-Walloca-larger-than=1 -Wformat-length=1 -flto -fpic -shared -o foo.so
-fdump-tree-optimized t.c
t.c: In function ‘f’:
t.c:3:9: warning: argument to ‘alloca’ is too large [-Walloca-larger-than=]
   char *d = (char *)__builtin_alloca (2);
 ^
t.c:3:9: note: limit is 1 bytes, but argument is 2
+ cat t.c.227t.optimized

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

f ()
{
  char * d;
  int _5;

   [100.00%]:
  d_3 = __builtin_alloca (2);
  _5 = __builtin_sprintf (d_3, "%i", 123);
  return _5;

}



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

g ()
{
   [100.00%]:
  return 3;

}

[Bug driver/78877] Missing suggestion for -fsanitize=addres

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Should be fixed by r244325; marking as resolved.

[Bug c++/77812] [5/6/7 Regression] incorrectly rejects valid C++ code that uses enum in template instantiation

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
The struct variant only 'works' because 'struct X' is a valid incomplete struct
declaration.  Try:

struct f {};

template 
void f ()
{
  struct f Q;
}

template void f ();

 void f() void f() [with  = int]
../../../77812-struct.ii: In instantiation of 'void f() [with
 = int]':
../../../77812-struct.ii:9:23:   required from here
../../../77812-struct.ii:6:12: error: 'f() [with  =
int]::f Q' has incomplete type
   struct f Q;
^

[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Wed Jan 11 17:28:52 2017
New Revision: 244326

URL: https://gcc.gnu.org/viewcvs?rev=244326=gcc=rev
Log:
PR c/78768 - -Walloca-larger-than and -Wformat-length warnings disabled by
-flto

gcc/ChangeLog:
* c.opt (-Walloca-larger-than, -Wformat-length, -Wformat-truncation):
Also enable for LTO.

gcc/testsuite/ChangeLog:
PR c/78768
* gcc.dg/pr78768.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr78768.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/testsuite/ChangeLog

[Bug driver/78877] Missing suggestion for -fsanitize=addres

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Wed Jan 11 17:25:40 2017
New Revision: 244325

URL: https://gcc.gnu.org/viewcvs?rev=244325=gcc=rev
Log:
Offer suggestions for unrecognized sanitizer options (PR driver/78877)

gcc/ChangeLog:
PR driver/78877
* opts.c: Include "spellcheck.h"
(struct string_fragment): New struct.
(struct edit_distance_traits): New
struct.
(get_closest_sanitizer_option): New function.
(parse_sanitizer_options): Offer suggestions for unrecognized
arguments.

gcc/testsuite/ChangeLog:
PR driver/78877
* gcc.dg/spellcheck-options-14.c: New test case.
* gcc.dg/spellcheck-options-15.c: New test case.
* gcc.dg/spellcheck-options-16.c: New test case.
* gcc.dg/spellcheck-options-17.c: New test case.


Added:
trunk/gcc/testsuite/gcc.dg/spellcheck-options-14.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-15.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-16.c
trunk/gcc/testsuite/gcc.dg/spellcheck-options-17.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/61450] ICE in gfc_global_used()

[fxcoudert at gcc dot gnu.org]

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

--- Comment #4 from Francois-Xavier Coudert  ---
Can regtest it and submit it to the list for review? Many thanks…

[Bug lto/79042] LTO doesn't propagate node->dynamically_initialized bit for varpool nodes.

[chefmax at gcc dot gnu.org]

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

--- Comment #3 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Wed Jan 11 16:53:52 2017
New Revision: 244324

URL: https://gcc.gnu.org/viewcvs?rev=244324=gcc=rev
Log:
PR lto/79042
* lto-cgraph.c (lto_output_varpool_node): Pack dynamically_initialized
bit.
(input_varpool_node): Unpack dynamically_initialized bit.
* lto-streamer.h (LTO_minor_version): Bump version.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/lto-cgraph.c
branches/gcc-6-branch/gcc/lto-streamer.h

[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Robert Schiele from comment #3)
> If you point me to the specific patch that you have in mind I can in
> parallel already test whether besides the test case I provided it also fixes
> the original problem this was detected with.

I've posted a patch for review at:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00736.html
It should apply to a GCC 6-based tree (but not GCC 7 trunk which doesn't
exhibit this bug)

[Bug target/78253] [5/6/7 Regression] [ARM] call weak function instead of strong when called through pointer

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon  ---
Author: clyon
Date: Wed Jan 11 16:13:14 2017
New Revision: 244320

URL: https://gcc.gnu.org/viewcvs?rev=244320=gcc=rev
Log:
[ARM] PR target/78253 Call weak function instead of strong when called through
pointer.

2017-01-11  Christophe Lyon  

PR target/78253
* config/arm/arm.c (legitimize_pic_address): Handle reference to
weak symbol.
(arm_assemble_integer): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug c++/77812] [5/6/7 Regression] incorrectly rejects valid C++ code that uses enum in template instantiation

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug fortran/79060] gfortran ICE with deferred-length character component initialization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
The ICE has been fixed between revisions r238055 (2016-07-06, ICE) and r238680
(2016-07-24, compiles). I see the ICE with GCC 5.4.0, but not with GCC 5.4.1
r242888 (2016-11-26). So it seems likely that the PR will be fixed for 5.5 and
it is fixed for 6.3 and trunk (7.0). So closing as FIXED.

Note that I did not find an obvious candidate back-ported to the 5 branch
between Nov 12 and 26.

[Bug other/79046] g++ -print-file-name=plugin uses full version number in path

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
There is no such guarantee, it can change any time, even in changes not
reflected in X.Y.Z version.  That said, after X.1 is released, they change not
very frequently.

[Bug other/79046] g++ -print-file-name=plugin uses full version number in path

[boris at kolpackov dot net]

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

--- Comment #4 from Boris Kolpackov  ---
Another question is whether GCC guarantees that its APIs (as can be used by a
plugin; e.g., AST) are binary compatible across Y.Z in GCC X.Y.Z?

[Bug testsuite/79051] FAIL: gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Target|poerpc64*-*-*   |poerpc64*-*-*,
   ||arm-none-linux-gnueabihf,
   ||m68k-*-*

--- Comment #2 from Martin Sebor  ---
As mentioned in the followup posts below, the the same assertion and fails on
arm-none-linux-gnueabihf and m68-*-*:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00696.html
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00680.html

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Richard Earnshaw from comment #17)
> (In reply to Jakub Jelinek from comment #15)
> 
> > Unless people commonly use
> > RUNTESTFLAGS='--target_board=unix\{-mtune=cortex-a15,-mtune=cortex-m7\}' or
> > something similar, that might work well.  The amount of tests that use
> > -mtune= in dg-options or dg-additional-options across all arches is big, so
> > most likely such RUNTESTFLAGS wouldn't be a very good idea.
> 
> 
> I think you're confusing ARM's use of -mtune with x86's.  The x86 equivalent
> of -mtune on ARM is -mcpu: it is rare to see -mtune in testsuite runs.
> 
> (On ARM there are two main options here -- -march and -mtune: -march selects
> the permitted instructions; -mtune controls how to pick from within the
> permitted set.  -mcpu is a convenience option that controls both options at
> the same time).

>From your description x86 -mtune is exactly what arm -mtune is, select CPU to
tune for within the ISA chosen by other options (so something that affects
scheduling choices, costs etc.).  My comment has been mainly about the flags
comming from --target_board being appended after dg-options, i.e. that if
-mtune= would be commonly used in --target_board, then it wouldn't work well.
If it is not used and people use -march= or -mcpu= there instead, then using
/* { dg-additional-options "-mtune=..." { target ... } } */
is fine.

[Bug lto/79061] New: [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

[burnus at gcc dot gnu.org]

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

Bug ID: 79061
   Summary: [7 Regression][LTO][ASAN] LTO plus ASAN fails with
"AddressSanitizer: initialization-order-fiasco"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40504=edit
Test case: untar (creates test/ subdir) and run "make" (or "g++ -g -O0 -flto
-fsanitize=address *.cc && ./a.out")

The attached test case (tar ball) consists of 5 .h/.cc files with 50 LoC in
total (also counting #if def and empty lines).


Running "make" fails with:

rm -f a.out
g++ -g -O0 -flto -fsanitize=address xptimer.cc xptiming.cc test.cc
./a.out
=
==13105==ERROR: AddressSanitizer: initialization-order-fiasco on address
0x00601540 at pc 0x00400a66 bp 0x7ffc758b0b40 sp 0x7ffc758b0b38


Works without LTO or with GCC 6 - and I believe there is no init order problem
in the attached code.

[Bug fortran/79060] New: gfortran ICE with deferred-length character component initialization

[david.sagan at gmail dot com]

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

Bug ID: 79060
   Summary: gfortran ICE with deferred-length character component
initialization
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.sagan at gmail dot com
  Target Milestone: ---

Test program is:

program test
type my_type
  character(:), allocatable :: c
end type
type (my_type) var
var = my_type()
end program

Compiler:
mc66:~/Bmad/test> gcc --version
gcc (MacPorts gcc5 5.4.0_0) 5.4.0

Compiling gives:

mc66:~/Bmad/test> gfortran test.f90
test.f90:9:0:

 var = my_type()
 1
internal compiler error: in
alloc_scalar_allocatable_for_subcomponent_assignment, at
fortran/trans-expr.c:6842

test.f90:9:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)

Note: No bug with gcc 6.3.0

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[rearnsha at gcc dot gnu.org]

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

--- Comment #17 from Richard Earnshaw  ---
(In reply to Jakub Jelinek from comment #15)

> Unless people commonly use
> RUNTESTFLAGS='--target_board=unix\{-mtune=cortex-a15,-mtune=cortex-m7\}' or
> something similar, that might work well.  The amount of tests that use
> -mtune= in dg-options or dg-additional-options across all arches is big, so
> most likely such RUNTESTFLAGS wouldn't be a very good idea.


I think you're confusing ARM's use of -mtune with x86's.  The x86 equivalent of
-mtune on ARM is -mcpu: it is rare to see -mtune in testsuite runs.

(On ARM there are two main options here -- -march and -mtune: -march selects
the permitted instructions; -mtune controls how to pick from within the
permitted set.  -mcpu is a convenience option that controls both options at the
same time).

[Bug tree-optimization/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> So, is what gcc trunk generates less efficient than what it used to generate
> before, or is just different?  If the latter, surely the test should be
> adjusted.

I will check it.  Sorry for missing this.  I suppose that revision is mine.

Thanks.

[Bug tree-optimization/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
So, is what gcc trunk generates less efficient than what it used to generate
before, or is just different?  If the latter, surely the test should be
adjusted.

[Bug rtl-optimization/78255] [5/6 regression] Indirect sibling call causing wrong code generation for ARM

[avieira at gcc dot gnu.org]

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

--- Comment #15 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Wed Jan 11 15:08:25 2017
New Revision: 244319

URL: https://gcc.gnu.org/viewcvs?rev=244319=gcc=rev
Log:
PR78255: Make postreload aware of NO_FUNCTION_CSE

gcc/ChangeLog:
2017-01-11  Andre Vieira 

Backport from mainline
2016-12-09  Andre Vieira 

PR rtl-optimization/78255
* gcc/postreload.c (reload_cse_simplify): Do not CSE a function if
NO_FUNCTION_CSE is true.

gcc/testsuite/ChangeLog:
2017-01-11  Andre Vieira 

Backport from mainline
2016-12-20  Andre Vieira  

* gcc.target/arm/pr78255-2.c: Fix to work for targets
that do not optimize for tailcall.

2017-01-11  Andre Vieira 

Backport from mainline
2016-12-09  Andre Vieira 

PR rtl-optimization/78255
* gcc.target/aarch64/pr78255.c: New.
* gcc.target/arm/pr78255-1.c: New.
* gcc.target/arm/pr78255-2.c: New.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/pr78255.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr78255-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/pr78255-2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/postreload.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[thopre01 at gcc dot gnu.org]

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

--- Comment #16 from Thomas Preud'homme  ---
FYI: -mtune=cortex-a15 works for an arm-none-eabi toolchain targetting
Cortex-M7

[Bug target/78397] The stack is not 8 bytes aligned on ARM

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
The __aeabi_read_tp call is to a special helper function and not really
considered to be a 'public interface'; the EABI only requires conformance to
the stack alignment constraints at public interfaces.

As such, I think that really this is a bug in the clang helper libraries and
that they shouldn't be making such an assumption.

The proposed patch is undesirable as it would extra stack activity in genuine
leaf functions as well as in this case and that makes the code less efficient.

[Bug ipa/78599] [7 Regression] hwint.h:292:72: runtime error: shift exponent 64 is too large for 64-bit type 'long int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Assuming fixed.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to ktkachov from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > So do you want something like:
> > /* { dg-skip-if "avoid conflicts with multilib options" { arm*-*-* } {
> > "-mcpu=*" } { "-mcpu=cortex-a15" } } */
> > /* { dg-additional-options "-mcpu=cortex-a15" { target arm*-*-* } } */
> > and remove the xfail?
> > cortex-a15 is randomly chosen non-cortex-m7 CPU, I don't know anything about
> > the ARM CPUs and what branch costs they have.
> > In any case, please resolve this soon, for a small testsuite glitch
> > (occassional XFAIL) keeping open P3 regression for so long is wasteful.
> 
> I'd be happy with any tuning that makes this pass. I'll check with
> cortex-a15.
> Also, I suggest just using
> /* { dg-additional-options "-mtune=cortex-a15" { target arm*-*-* } } */
> That will use the cortex-a15 tuning (including BRANCH_COST) but will not
> enforce any architectural features, so should avoid the need for the
> multilib stuff

Unless people commonly use
RUNTESTFLAGS='--target_board=unix\{-mtune=cortex-a15,-mtune=cortex-m7\}' or
something similar, that might work well.  The amount of tests that use -mtune=
in dg-options or dg-additional-options across all arches is big, so most likely
such RUNTESTFLAGS wouldn't be a very good idea.

[Bug libstdc++/78273] The transparent version of {map,set}::count should call _M_count_tr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |5.5
  Known to fail||5.4.0, 6.3.0

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/78134] set::set lower_bound() for transparent comparator returns const_iterator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|6.4 |5.5
  Known to fail||5.4.0, 6.3.0

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #14 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #13)
> So do you want something like:
> /* { dg-skip-if "avoid conflicts with multilib options" { arm*-*-* } {
> "-mcpu=*" } { "-mcpu=cortex-a15" } } */
> /* { dg-additional-options "-mcpu=cortex-a15" { target arm*-*-* } } */
> and remove the xfail?
> cortex-a15 is randomly chosen non-cortex-m7 CPU, I don't know anything about
> the ARM CPUs and what branch costs they have.
> In any case, please resolve this soon, for a small testsuite glitch
> (occassional XFAIL) keeping open P3 regression for so long is wasteful.

I'd be happy with any tuning that makes this pass. I'll check with cortex-a15.
Also, I suggest just using
/* { dg-additional-options "-mtune=cortex-a15" { target arm*-*-* } } */
That will use the cortex-a15 tuning (including BRANCH_COST) but will not
enforce any architectural features, so should avoid the need for the multilib
stuff

[Bug libstdc++/78134] set::set lower_bound() for transparent comparator returns const_iterator

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Jan 11 14:44:15 2017
New Revision: 244318

URL: https://gcc.gnu.org/viewcvs?rev=244318=gcc=rev
Log:
PR78134 fix return types of heterogeneous lookup functions

PR libstdc++/78134
* include/bits/stl_map.h (map::lower_bound, map::upper_bound)
(map::equal_range): Fix return type of heterogeneous overloads.
* include/bits/stl_multimap.h (multimap::lower_bound)
(multimap::upper_bound, multimap::equal_range): Likewise.
* include/bits/stl_multiset.h (multiset::lower_bound)
(multiset::upper_bound, multiset::equal_range): Likewise.
* include/bits/stl_set.h (set::lower_bound, set::upper_bound)
(set::equal_range): Likewise.
* testsuite/23_containers/map/operations/2.cc
* testsuite/23_containers/multimap/operations/2.cc
* testsuite/23_containers/multiset/operations/2.cc
* testsuite/23_containers/set/operations/2.cc

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_map.h
trunk/libstdc++-v3/include/bits/stl_multimap.h
trunk/libstdc++-v3/include/bits/stl_multiset.h
trunk/libstdc++-v3/include/bits/stl_set.h
trunk/libstdc++-v3/testsuite/23_containers/map/operations/2.cc
trunk/libstdc++-v3/testsuite/23_containers/multimap/operations/2.cc
trunk/libstdc++-v3/testsuite/23_containers/multiset/operations/2.cc
trunk/libstdc++-v3/testsuite/23_containers/set/operations/2.cc

[Bug libstdc++/78273] The transparent version of {map,set}::count should call _M_count_tr

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed Jan 11 14:44:04 2017
New Revision: 244317

URL: https://gcc.gnu.org/viewcvs?rev=244317=gcc=rev
Log:
PR78273 fix count to work with partitioning function

PR libstdc++/78273
* include/bits/stl_map.h (map::count<_Kt>(const _Kt&)): Don't assume
the heterogeneous comparison can only find one match.
* include/bits/stl_set.h (set::count<_Kt>(const _Kt&)): Likewise.
* testsuite/23_containers/map/operations/2.cc: Test count works with
comparison function that just partitions rather than sorting.
* testsuite/23_containers/set/operations/2.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_map.h
trunk/libstdc++-v3/include/bits/stl_set.h
trunk/libstdc++-v3/testsuite/23_containers/map/operations/2.cc
trunk/libstdc++-v3/testsuite/23_containers/set/operations/2.cc

[Bug c++/77598] constexpr compilation failure on reference type casting

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
The warning is gone with r242523.

[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
So do you want something like:
/* { dg-skip-if "avoid conflicts with multilib options" { arm*-*-* } {
"-mcpu=*" } { "-mcpu=cortex-a15" } } */
/* { dg-additional-options "-mcpu=cortex-a15" { target arm*-*-* } } */
and remove the xfail?
cortex-a15 is randomly chosen non-cortex-m7 CPU, I don't know anything about
the ARM CPUs and what branch costs they have.
In any case, please resolve this soon, for a small testsuite glitch
(occassional XFAIL) keeping open P3 regression for so long is wasteful.