[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

[chefmax at gcc dot gnu.org]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||chefmax at gcc dot gnu.org

--- Comment #2 from Maxim Ostapenko  ---
Here another reprocase (diamond inheritance):
==

struct A {
  int x;
  virtual ~A() {}
};

struct B: public virtual A {
};

struct C: public virtual A {
};

struct D: public B, virtual public C {
};

int main() {
  D d;
}


==24761==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x71d86bf8 at pc 0x400e1b bp 0x71d86b70 sp 0x71d86b68
WRITE of size 24 at 0x71d86bf8 thread T0
#0 0x400e1a in C::~C() (/home/max/build/gcc-upstream-x86_64/a.out+0x400e1a)
#1 0x401257 in D::~D() (/home/max/build/gcc-upstream-x86_64/a.out+0x401257)
#2 0x400a8b in main (/home/max/build/gcc-upstream-x86_64/a.out+0x400a8b)
#3 0x7f7487a1676c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#4 0x400918 (/home/max/build/gcc-upstream-x86_64/a.out+0x400918)

Address 0x71d86bf8 is located in stack of thread T0 at offset 56 in frame
#0 0x400a17 in main (/home/max/build/gcc-upstream-x86_64/a.out+0x400a17)

  This frame has 1 object(s):
[32, 64) 'd' <== Memory access at offset 56 partially overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 C::~C()
Shadow bytes around the buggy address:
  0x10007e3a8d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e3a8d30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e3a8d40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e3a8d50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e3a8d60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007e3a8d70: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00[00]
  0x10007e3a8d80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e3a8d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e3a8da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e3a8db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007e3a8dc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  ASan internal:   fe
==24761==ABORTING

Compiled with recent GCC version:
GNU C++ (GCC) version 5.0.0 20140916 (experimental) (x86_64-unknown-linux-gnu)

[Bug c++/63290] [C++11] alias declaration with exception specification should cause compilation error

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-18
 Ever confirmed|0   |1

[Bug libstdc++/62160] std::uppercase does not work for std::hex output

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution|--- |INVALID

--- Comment #2 from Paolo Carlini  ---
Closing.

[Bug testsuite/63291] New: ASan reports stack-buffer-overflow in some cilkplus tests.

[chefmax at gcc dot gnu.org]

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

Bug ID: 63291
   Summary: ASan reports stack-buffer-overflow in some cilkplus
tests.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chefmax at gcc dot gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

These tests failed with stack-buffer-overflow if run with ASan enabled:

FAIL: c-c++-common/cilk-plus/AN/if_test.c  -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c  -O1 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c  -O2 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c  -O3 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c  -g -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c  -g -O2 -ftree-vectorize -fcilkplus
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c  -fcilkplus -std=c99 execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c  -fcilkplus -O2 -std=c99 execution
test
FAIL: c-c++-common/cilk-plus/AN/if_test.c  -fcilkplus -O3 -std=c99 execution
test
FAIL: c-c++-common/cilk-plus/AN/if_test.c  -fcilkplus -g -O0 -std=c99 execution
test

FAIL: c-c++-common/cilk-plus/CK/fib.c  -O1  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_init_expr_xy.c  -O1  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c  -O1  execution test
FAIL: c-c++-common/cilk-plus/CK/fib.c  -O2 -std=c99  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_init_expr_xy.c  -O2 -std=c99  execution
test
FAIL: c-c++-common/cilk-plus/CK/fib_no_return.c  -O2 -std=c99  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c  -O2 -std=c99  execution test
FAIL: c-c++-common/cilk-plus/CK/fib.c  -O2 -ftree-vectorize  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_init_expr_xy.c  -O2 -ftree-vectorize 
execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_return.c  -O2 -ftree-vectorize 
execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c  -O2 -ftree-vectorize  execution
test
FAIL: c-c++-common/cilk-plus/CK/fib.c  -O3 -g  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_init_expr_xy.c  -O3 -g  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_return.c  -O3 -g  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c  -O3 -g  execution test
FAIL: c-c++-common/cilk-plus/CK/fib.c  -O3 -flto -g  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_init_expr_xy.c  -O3 -flto -g  execution
test
FAIL: c-c++-common/cilk-plus/CK/fib_no_return.c  -O3 -flto -g  execution test
FAIL: c-c++-common/cilk-plus/CK/fib_no_sync.c  -O3 -flto -g  execution test

[Bug c++/61716] internal compiler error: Seg Fault

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  ---
Not a bug report. Before filing a proper one, please make sure that the issue
reproduces at least on 4.8.x.

[Bug c++/61678] [5 Regression] internal compiler error: in expand_expr_real_1, at expr.c:9467

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-18
Summary|internal compiler error: in |[5 Regression] internal
   |expand_expr_real_1, at  |compiler error: in
   |expr.c:9467 |expand_expr_real_1, at
   ||expr.c:9467
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
I doubt it's a front-end issue.

[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

[chefmax at gcc dot gnu.org]

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

--- Comment #3 from Maxim Ostapenko  ---
Test fails only if compile on -O0 and -Os optimization levels:

$ ~/install/master/bin/g++ diamond_virt.cc -fsanitize=address -Os

On -O1, -O2 and -O3 ASan does not report any error.

[Bug testsuite/63292] New: ASan reports global-buffer-overflow in gcc.dg/vect/pr59594.c.

[chefmax at gcc dot gnu.org]

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

Bug ID: 63292
   Summary: ASan reports global-buffer-overflow in
gcc.dg/vect/pr59594.c.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chefmax at gcc dot gnu.org
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

This test fails at line 20 with global buffer overflow:

$ ~/install/master/bin/gcc ~/gcc/gcc/testsuite/gcc.dg/vect/pr59594.c
-fsanitize=address -msse2 -ftree-vectorize -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details -lm -o ./pr59594.exe

$ ./pr59594.exe

=
==2059==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00602384 at pc 0x400a4d bp 0x7fff0d9f5300 sp 0x7fff0d9f52f8
WRITE of size 4 at 0x00602384 thread T0
#0 0x400a4c in main
(/home/max/build/master-x86_64/gcc/testsuite/gcc/pr59594.exe+0x400a4c)
#1 0x2b523822176c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#2 0x400aa4
(/home/max/build/master-x86_64/gcc/testsuite/gcc/pr59594.exe+0x400aa4)

0x00602384 is located 0 bytes to the right of global variable 'b' from
'/home/max/workspace/downloads/gcc/gcc/testsuite/gcc.dg/vect/pr59594.c'
(0x601380) of size 4100
SUMMARY: AddressSanitizer: global-buffer-overflow ??:0 main
Shadow bytes around the buggy address:
  0x800b8420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800b8430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800b8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800b8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800b8460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x800b8470:[04]f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x800b8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800b8490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800b84a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800b84b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800b84c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  ASan internal:   fe
==2059==ABORTING

[Bug c/61405] Not emitting "enumeration value not handled in switch" warning for bit-field enums

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |5.0

--- Comment #5 from Marek Polacek  ---
I'll give this a try.

[Bug c++/61745] template friend for dyadic operator- is only accepted if the monadic operator- follows it

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
I'm adding the testcase and closing the bug.

[Bug c/61405] Not emitting "enumeration value not handled in switch" warning for bit-field enums

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
/* PR c/61405 */
/* { dg-do compile } */
/* { dg-options "-Wswitch" } */

enum E { A, B, C };
struct S { enum E e:2; };

int
foo (struct S *s) 
{
  switch (s->e) /* { dg-warning "enumeration value .C. not handled in switch" }
*/
{   
case A:
  return 1;
case B:
  return 2;
}   
}

[Bug c/63293] New: [AArch64] can read from deallocated stack

[jiong.wang at arm dot com]

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

Bug ID: 63293
   Summary: [AArch64] can read from deallocated stack
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiong.wang at arm dot com

With GCC: (GNU) 5.0.0 20140917

give the following testcase


  typedef double t;

  void bar (t*);

  t g ()
  {
t data[8192];

data[4293] = data[4266] = 0;
bar(data);
return data[4293] + data[4266];
  }

Compiling with "-O2 -mno-lra -fomit-frame-pointer" we get:

.cpu generic+fp+simd
.file   "test.c"
.text
.align  2
.global f
.type   f, %function
f:
add x1, x0, 4093
add x0, x0, 4096
ldr d1, [x1]
ldr d0, [x0, 170]
faddd0, d1, d0
ret
.size   f, .-f
.align  2
.global g
.type   g, %function
g:
sub sp, sp, #65536
fmovd0, xzr
str x30, [sp, -16]!
add x1, sp, 32768
add x0, sp, 16
str d0, [x1, 1376]
str d0, [x1, 1592]
bl  bar
add x0, sp, 32768
ldr x30, [sp], 16
ldr d0, [x0, 1376]
add sp, sp, 65536
ldr d1, [x0, 1592]
faddd0, d1, d0
ret

  Note that at the end we have x0=sp+32768; sp+=65536; ldr [x0+1592]
  Which means the last load is from deallocated stack space.

  This is a silent wrong-code bug of the worst kind; programs could fail 
sporadically with this if an interrupt happens at the wrong instant in time and
data was written onto the current stack.

[Bug c++/61745] template friend for dyadic operator- is only accepted if the monadic operator- follows it

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Sep 18 09:15:25 2014
New Revision: 215345

URL: https://gcc.gnu.org/viewcvs?rev=215345&root=gcc&view=rev
Log:
2014-09-18  Paolo Carlini  

PR c++/61745
* g++.dg/template/pr61745.C: New.

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

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  ---
Jakub, do I understand correctly that this isn't a front-end issue?

[Bug c++/58281] Problem with explicit constexpr template functions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-18
 Blocks||55004
 Ever confirmed|0   |1

[Bug fortran/63294] New: ICE allocattion of array of type of type

[valeryweber at hotmail dot com]

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

Bug ID: 63294
   Summary: ICE allocattion of array of type of type
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com

[Bug c++/59899] Internal compiler error: Segmentation fault

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Closing.

[Bug c++/60239] False positive maybe-uninitialized in for loop

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-09-18
 Ever confirmed|0   |1

[Bug c++/61262] GCC segfaults

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Feedback not forthcoming.

[Bug c++/61133] g++ doesn't implement DR1760

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #3 from Paolo Carlini  ---
Thus done, right?

[Bug target/63234] arm used label is removed

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug c++/61392] internal compiler error: in write_template_arg_literal, at cp/mangle.c:3072

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-18
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
A mangling issue, CC-ing Jason.

[Bug target/56993] power gcc built 416.gamess generates wrong result

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Looking at 416.gamess, I see mess like:
$ cat /tmp/a.f90
  common /a/ i(10)
  i(:) = 1
  call foo (10)
end
$ cat /tmp/b.f90
subroutine foo (j)
  common /a/ i(1)
  l = 0
  do k = 1, j
l = l + i(k)
  end do
  print *, l
end subroutine foo
$ gfortran -o /tmp/a /tmp/a.f90 /tmp/b.f90 -O2 -Wall; /tmp/a; gfortran -o
/tmp/b /tmp/a.f90 /tmp/b.f90 -O2 -Wall -fno-aggressive-loop-optimizations;
/tmp/b; gfortran -o /tmp/c /tmp/a.f90 /tmp/b.f90; /tmp/c
   1
  10
  10

Is that valid Fortran at all?  To the middle-end, the array (at the end of) the
COMMON block is represented as a structure containing a fixed bound array, so
the middle-end (rightfully) thinks that only X(1) is valid, but X(2) and higher
are undefined behavior.  If Fortran as language allows this, either everywhere,
or for compatibility in some mode, it would be better if such common blocks
were modeled similarly to C99 flexible array members with GNU extension of
initializing that; which is that the type of last RECORD_TYPE's FIELD_DECL
should have NULL max bound, and only the VAR_DECL would have size reflecting
the actual array size.  Of course, only the last array in the COMMON block
could be handled this way, if some (broken?) Fortran code still wants say
COMMON /XX/ X(1), B, C, D, Y(20)
and happily access X(2) as B, X(3) as C, X(4) as D, X(6) as Y(2) etc., then
I'm afraid -fno-aggressive-loop-optimizations is the only thing to do for such
code (and probably more than that).
>From the comments in unport.F, it looks like 416.gamess has commented out even
far uglier hacks, in particular using the COMMON /FPCOM / X(1) and then
when accessing it biasing index by some variable, which is initialized as a
difference between a heap region and the array in the common block.  That would
be even worse for the middle-end and C semantics, dunno what Fortran as
language ever allowed and what needs to be (optionally?) tolerated to get badly
written code working.

[Bug c++/61465] Bogus parameter set but not used warning in constructor initialization list

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  ---
CC-ing Jakub about this too.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
That is to be determined.  Either it might be an x86_64 bug in passing such
types, or FE issue, middle-end.

[Bug c++/61133] g++ doesn't implement DR1760

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen  ---
Yep, done.

[Bug c++/61465] Bogus parameter set but not used warning in constructor initialization list

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
For:
struct Foo {
  Foo(void* x) : y{static_cast(x)} {}
  char* y;
};
struct Bar {
  Bar(void* x) : y(static_cast(x)) {}
  char* y;
};
the x parameter in Bar ctor is marked through:

#0  mark_exp_read (exp=) at ../../gcc/cp/expr.c:135
#1  0x0067af84 in mark_exp_read (exp=) at
../../gcc/cp/expr.c:146
#2  0x0067aea6 in mark_rvalue_use (expr=) at
../../gcc/cp/expr.c:99
#3  0x00623e29 in convert_like_real (convs=0x20d65a0, expr=, fn=, argnum=0, inner=0, 
issue_conversion_warnings=true, c_cast_p=false, complain=3) at
../../gcc/cp/call.c:6209
#4  0x00630bd3 in perform_implicit_conversion_flags (type=, expr=, complain=3, 
flags=1) at ../../gcc/cp/call.c:9315
#5  0x007bb105 in convert_for_assignment (type=, rhs=, errtype=ICR_INIT, 
fndecl=, parmnum=0, complain=3, flags=1) at
../../gcc/cp/typeck.c:8233
#6  0x007bb65f in convert_for_initialization (exp=, type=, 
rhs=, flags=1, errtype=ICR_INIT, fndecl=, parmnum=0, complain=3) at ../../gcc/cp/typeck.c:8324
#7  0x007b933d in cp_build_modify_expr (lhs=, modifycode=INIT_EXPR, rhs=, 
complain=3) at ../../gcc/cp/typeck.c:7593
#8  0x007ced80 in perform_member_init (member=, init=) at ../../gcc/cp/init.c:771
#9  0x007d0535 in emit_mem_initializers (mem_inits=) at ../../gcc/cp/init.c:1136
#10 0x007f895c in finish_mem_initializers (mem_inits=) at ../../gcc/cp/semantics.c:1603
#11 0x00767fa0 in cp_parser_mem_initializer_list
(parser=0x719fe000) at ../../gcc/cp/parser.c:12530
#12 0x00767b21 in cp_parser_ctor_initializer_opt
(parser=0x719fe000) at ../../gcc/cp/parser.c:12441
#13 0x0077311c in cp_parser_ctor_initializer_opt_and_function_body
(parser=0x719fe000, in_function_try_block=false)
at ../../gcc/cp/parser.c:18993
#14 0x0077adce in cp_parser_function_definition_after_declarator
(parser=0x719fe000, inline_p=true) at ../../gcc/cp/parser.c:23173
#15 0x0077cc6a in cp_parser_late_parsing_for_member
(parser=0x719fe000, member_function=)
at ../../gcc/cp/parser.c:23856

No idea what different code path is used for the {} initialization as opposed
to (), but supposedly somewhere in there we should call mark_rvalue_use or
mark_exp_read.

[Bug c++/61465] Bogus parameter set but not used warning in constructor initialization list

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
And on
struct Baz {
  Baz(char* x) : y{x} {}
  char* y;
};
x is marked through:
#0  mark_exp_read (exp=) at ../../gcc/cp/expr.c:135
#1  0x0067aea6 in mark_rvalue_use (expr=)
at ../../gcc/cp/expr.c:99
#2  0x007a53e6 in decay_conversion (exp=,
complain=3) at ../../gcc/cp/typeck.c:1915
#3  0x0062492c in convert_like_real (convs=0x20d6630, expr=, fn=, argnum=0, inner=0, 
issue_conversion_warnings=true, c_cast_p=false, complain=3) at
../../gcc/cp/call.c:6331
#4  0x00630bd3 in perform_implicit_conversion_flags (type=, expr=, complain=3, 
flags=1) at ../../gcc/cp/call.c:9315
#5  0x007bb105 in convert_for_assignment (type=, rhs=, errtype=ICR_INIT, 
fndecl=, parmnum=0, complain=3, flags=1) at
../../gcc/cp/typeck.c:8233
#6  0x007bb65f in convert_for_initialization (exp=, type=, 
rhs=, flags=1, errtype=ICR_INIT, fndecl=, parmnum=0, complain=3) at ../../gcc/cp/typeck.c:8324
#7  0x007b933d in cp_build_modify_expr (lhs=, modifycode=INIT_EXPR, rhs=, 
complain=3) at ../../gcc/cp/typeck.c:7593
#8  0x007ced80 in perform_member_init (member=, init=) at
../../gcc/cp/init.c:771
#9  0x007d0535 in emit_mem_initializers (mem_inits=) at ../../gcc/cp/init.c:1136
#10 0x007f895c in finish_mem_initializers (mem_inits=) at ../../gcc/cp/semantics.c:1603

cp_build_modify_expr is still called even in the Foo::Foo(void*) case, with
a CONSTRUCTOR containing NOP_EXPR of PARM_DECL, so either we should
mark_exp_read when creating the CONSTRUCTOR, which would be roughly in
cp_parser_initializer_list ??, or when processing the ctor.  Jason, any
preferences?

[Bug target/63293] [AArch64] can read from deallocated stack

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
I don't remember seeing a stack tie being emitted from the backend.

[Bug c++/63295] New: Insane memory use

[terra at gnome dot org]

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

Bug ID: 63295
   Summary: Insane memory use
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org

Compiling the (nonsense) program:

class x class
x

[Bug target/63293] [AArch64] can read from deallocated stack

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-18
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed

[Bug ipa/63270] [5 Regression] internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1075

[mliska at suse dot cz]

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

--- Comment #3 from Martin Liška  ---
The problem does not occur in mainline any more, starting with: r215328.

[Bug ipa/63270] [5 Regression] internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1075

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Martin Liška from comment #3)
> The problem does not occur in mainline any more, starting with: r215328.

Then maybe add the testcase and close both issues?

[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-09-18
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.  It makes no sense to instrument clobbers, so that is what the
patch does.

[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
CCing Jason whether the type on the MEM_REF in the clobber stmt in C::~C is
appropriate though.

[Bug c++/62232] -Wnon-virtual-dtor shouldn't warn on final classes

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Sep 18 13:48:33 2014
New Revision: 215351

URL: https://gcc.gnu.org/viewcvs?rev=215351&root=gcc&view=rev
Log:
/cp
2014-09-18  Paolo Carlini  

PR c++/62232
* class.c (finish_struct_1): Do not -Wnon-virtual-dtor warn
for final class types.

/testsuite
2014-09-18  Paolo Carlini  

PR c++/62232
* g++.dg/cpp0x/Wdtor1.C: New.

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

[Bug c++/62232] -Wnon-virtual-dtor shouldn't warn on final classes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #3 from Paolo Carlini  ---
Done.

[Bug testsuite/63292] ASan reports global-buffer-overflow in gcc.dg/vect/pr59594.c.

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 18 13:50:10 2014
New Revision: 215352

URL: https://gcc.gnu.org/viewcvs?rev=215352&root=gcc&view=rev
Log:
PR testsuite/63292
* gcc.dg/vect/pr59594.c (b): Increase size to N + 2 elements.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr59594.c

[Bug testsuite/63292] ASan reports global-buffer-overflow in gcc.dg/vect/pr59594.c.

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 18 13:51:02 2014
New Revision: 215353

URL: https://gcc.gnu.org/viewcvs?rev=215353&root=gcc&view=rev
Log:
PR testsuite/63292
* gcc.dg/vect/pr59594.c (b): Increase size to N + 2 elements.

Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr59594.c

[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 18 14:08:28 2014
New Revision: 215354

URL: https://gcc.gnu.org/viewcvs?rev=215354&root=gcc&view=rev
Log:
PR c++/62017
* asan.c (transform_statements): Don't instrument clobber statements.

* g++.dg/asan/pr62017.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/asan/pr62017.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 18 14:09:57 2014
New Revision: 215355

URL: https://gcc.gnu.org/viewcvs?rev=215355&root=gcc&view=rev
Log:
PR c++/62017
* asan.c (transform_statements): Don't instrument clobber statements.

* g++.dg/asan/pr62017.C: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/asan/pr62017.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/asan.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c++/62232] -Wnon-virtual-dtor shouldn't warn on final classes

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Paolo Carlini from comment #3)
> Done.

Thanks. It's unfortunate that one has to memorize hundreds of
macro names to be able to work in this area.

 gcc % cat gcc/cp/cp-tree.h | grep "^#define" | wc -l
815

[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #5)
> CCing Jason whether the type on the MEM_REF in the clobber stmt in C::~C is
> appropriate though.

What MEM_REF?  Compiling with -fdump-tree-gimple the only clobber I see is

*this = {CLOBBER};

are you suggesting that we should only clobber the CLASSTYPE_AS_BASE subset of
*this?  That makes sense.

[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #8)
> (In reply to Jakub Jelinek from comment #5)
> > CCing Jason whether the type on the MEM_REF in the clobber stmt in C::~C is
> > appropriate though.
> 
> What MEM_REF?  Compiling with -fdump-tree-gimple the only clobber I see is
> 
> *this = {CLOBBER};
> 
> are you suggesting that we should only clobber the CLASSTYPE_AS_BASE subset
> of *this?  That makes sense.

*this is actually MEM_REF with some type, and yeah, I mean that
clobber.
Don't know how exactly CLASSTYPE_AS_BASE differs from the type of *this to know
what should be clobbered, the clobber should say as accurately as possible what
becomes undefined after the dtor ends, so that e.g. stores to fields in the
class can be DSEd if nothing uses them until the destructor.

[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Created attachment 33511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33511&action=edit
patch to dtor clobbers

Like this?

[Bug target/56993] power gcc built 416.gamess generates wrong result

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
  Some SPEC benchmarks contain questionable code.  It is true for SPEC2000 and
true for SPEC2006.  So the PR is not a surprise for me.

  Unfortunately, nobody from GCC community participates in SPEC org which
chooses the benchmarks.  Intel is a major player there (besides Sun in the
past) and they mostly care only about their compilers.

  Also in SPEC2006 they made very difficult to change the benchmark code (by
checking control sum of the code).

[Bug c++/63296] New: g++ reports incomplete type for static template member of template class

[rogier777 at gmail dot com]

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

Bug ID: 63296
   Summary: g++ reports incomplete type for static template member
of template class
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogier777 at gmail dot com

G++ fails to compile the following code. IMHO, as 'staticmember' is a static
member, the code is valid and should be accepted.

Moving 'staticmember' outside the class (making it a plain static variable),
makes g++ accept the code.

Making 'myclass' a regular (non-template) class instead makes g++ accept the
code as well.

Code:
---
template
struct list {
c member;
};

template
struct myclass {
static list staticmember;
};

myclass myvar;
---

Compilation output (extended version with '-v -save-temps' below):
---
$ g++ -W -Wall --std=c++11 -o /dev/null try_01c.cc
try_01c.cc: In instantiation of ‘struct list >’:
try_01c.cc:9:26:   required from ‘struct myclass’
try_01c.cc:12:14:   required from here
try_01c.cc:4:7: error: ‘list::member’ has incomplete type
 c member;
   ^
try_01c.cc:8:8: error: declaration of ‘struct myclass’
 struct myclass {
^
---

G++ version: 4.9
(Stock debian package version 4.9.1-14)

Detailed compiler output with '-v -save-temps':
---
$ g++ -W -Wall --std=c++11 -v -save-temps -o /dev/null try_01c.cc
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.9.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-linux-gnu/4.9/lto-wrapper
Target: i586-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-14'
--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-i386/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=i586-linux-gnu --host=i586-linux-gnu
--target=i586-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-14) 
COLLECT_GCC_OPTIONS='-Wextra' '-Wall' '-std=c++11' '-v' '-save-temps' '-o'
'/dev/null' '-shared-libgcc' '-mtune=generic' '-march=i586'
 /usr/lib/gcc/i586-linux-gnu/4.9/cc1plus -E -quiet -v -imultiarch
i386-linux-gnu -D_GNU_SOURCE try_01c.cc -mtune=generic -march=i586 -std=c++11
-Wextra -Wall -fpch-preprocess -o try_01c.ii
ignoring duplicate directory "/usr/include/i386-linux-gnu/c++/4.9"
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i586-linux-gnu/4.9/../../../../i586-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.9
 /usr/include/i386-linux-gnu/c++/4.9
 /usr/include/c++/4.9/backward
 /usr/lib/gcc/i586-linux-gnu/4.9/include
 /usr/local/include
 /usr/lib/gcc/i586-linux-gnu/4.9/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-Wextra' '-Wall' '-std=c++11' '-v' '-save-temps' '-o'
'/dev/null' '-shared-libgcc' '-mtune=generic' '-march=i586'
 /usr/lib/gcc/i586-linux-gnu/4.9/cc1plus -fpreprocessed try_01c.ii -quiet
-dumpbase try_01c.cc -mtune=generic -march=i586 -auxbase try_01c -Wextra -Wall
-std=c++11 -version -o try_01c.s
GNU C++ (Debian 4.9.1-14) version 4.9.1 (i586-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version
3.1.2-p3, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Debian 4.9.1-14) version 4.9.1 (i586-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version
3.1.2-p3, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4eca7bfa4a918deb01db62dfdef571b2
try_01c.cc: In instantiation of ‘struct list >’:
try_01c.cc:9:26:   required from ‘struct myclass’
try_01c.cc:12:14:   required from here
try_0

[Bug testsuite/63297] New: ASan reported heap-use-after-free in g++.old-deja/g++.law/virtual3.C.

[chefmax at gcc dot gnu.org]

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

Bug ID: 63297
   Summary: ASan reported heap-use-after-free in
g++.old-deja/g++.law/virtual3.C.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chefmax at gcc dot gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 33512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33512&action=edit
This trivial patch seems to fix the issue.

ASan reported heap-use-after-free in g++.old-deja/g++.law/virtual3.C:

$ ~/install/master/bin/g++ gcc/testsuite/g++.old-deja/g++.law/virtual3.C
-fsanitize=address

$ ./a.out

=
==26271==ERROR: AddressSanitizer: heap-use-after-free on address 0x6030eff8
at pc 0x7fd84fbb6470 bp 0x7fff4d8204a0 sp 0x7fff4d81fc60
READ of size 5 at 0x6030eff8 thread T0
#0 0x7fd84fbb646f in __interceptor_strlen
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_interceptors.cc:536
#1 0x7fd84f8ed2d8 in std::char_traits::length(char const*)
/home/max/build/master-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/char_traits.h:263
#2 0x7fd84f8ed2d8 in std::basic_ostream >&
std::operator<<  >(std::basic_ostream >&, char const*)
/home/max/build/master-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/include/ostream:536
#3 0x401515 in BugStream::eval()
(/home/max/workspace/downloads/gcc/a.out+0x401515)
#4 0x4015ef in operator<<(std::ostream&, Eval_)
(/home/max/workspace/downloads/gcc/a.out+0x4015ef)
#5 0x401699 in main (/home/max/workspace/downloads/gcc/a.out+0x401699)
#6 0x7fd84efa576c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#7 0x4013c8 (/home/max/workspace/downloads/gcc/a.out+0x4013c8)

0x6030eff8 is located 24 bytes inside of 30-byte region
[0x6030efe0,0x6030effe)
freed by thread T0 here:
#0 0x7fd84fbf36a9 in operator delete(void*)
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_new_delete.cc:85
#1 0x7fd84f914eef in std::string::_Rep::_M_dispose(std::allocator
const&)
/home/max/build/master-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:249
#2 0x7fd84f914eef in std::basic_string,
std::allocator >::~basic_string()
/home/max/build/master-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:547
#3 0x4015ef in operator<<(std::ostream&, Eval_)
(/home/max/workspace/downloads/gcc/a.out+0x4015ef)
#4 0x401699 in main (/home/max/workspace/downloads/gcc/a.out+0x401699)
#5 0x7fd84efa576c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)

previously allocated by thread T0 here:
#0 0x7fd84fbf3169 in operator new(unsigned long)
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_new_delete.cc:53
#1 0x7fd84f914d18 in __gnu_cxx::new_allocator::allocate(unsigned
long, void const*)
/home/max/build/master-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:104
#2 0x7fd84f914d18 in std::string::_Rep::_S_create(unsigned long, unsigned
long, std::allocator const&)
/home/max/build/master-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:607

SUMMARY: AddressSanitizer: heap-use-after-free
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_interceptors.cc:536
__interceptor_strlen
Shadow bytes around the buggy address:
  0x0c067fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c067fff9df0: fa fa fa fa fa fa fa fa fa fa fa fa fd fd fd[fd]
  0x0c067fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  ASan internal:   fe
==26271==ABORTING

[Bug target/56993] power gcc built 416.gamess generates wrong result

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #7 from ktkachov at gcc dot gnu.org ---
> I'm afraid -fno-aggressive-loop-optimizations is the only thing to do for
> such code (and probably more than that).

Yeah, I use -fno-aggressive-loop-optimizations on gamess in my runs, I was
getting miscompares otherwise

[Bug ipa/63298] New: [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO

[mliska at suse dot cz]

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

Bug ID: 63298
   Summary: [5 Regression] internal compiler error: in
types_same_for_odr, at ipa-devirt.c:449 with LTO
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

After fixed issued PR63270 with r215328, it looks there's a new ICE in Chrome
with LTO:

bt
lto1: internal compiler error: in types_same_for_odr, at ipa-devirt.c:449
0x6f9eba types_same_for_odr(tree_node const*, tree_node const*)
../../gcc/ipa-devirt.c:449
0x6fa0a2 odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:535
0x6fb5db odr_types_equivalent_p
../../gcc/ipa-devirt.c:1026
0x6fbd37 add_type_duplicate
../../gcc/ipa-devirt.c:1191
0x6fc143 get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:1339
0x6fc472 register_odr_type(tree_node*)
../../gcc/ipa-devirt.c:1407
0x56c15e lto_read_decls
../../gcc/lto/lto.c:1918
0x56d068 lto_file_finalize
../../gcc/lto/lto.c:2212
0x56d068 lto_create_files_from_ids
../../gcc/lto/lto.c:
0x56d068 lto_file_read
../../gcc/lto/lto.c:2263
0x56d068 read_cgraph_and_symbols
../../gcc/lto/lto.c:2966
0x56d068 lto_main()
../../gcc/lto/lto.c:3420


where type1 at ipa-devirt.c:449 is:
 
unit size 
align 8 symtab 0 alias set 0 canonical type 0x76c323f0 precision 8
min  max 
pointer_to_this  reference_to_this
>
SI
size  constant 32>
unit size  constant 4>
align 8 symtab 0 alias set 0 canonical type 0x769b6f18
domain 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76c32888
precision 64 min  max 
pointer_to_this >
DI size  unit size 
align 64 symtab 0 alias set 0 canonical type 0x76c327e0 precision
64 min  max >
pointer_to_this >

Unfortunately, it looks very hard to isolate a few objects (libraries) for
Chrome, my current minimum command-line is still following:

c++  -fPIC -pie -L. -O2 -flto=7 -Wl,--start-group  
obj/chrome/app/chrome_initial.chrome_main.oobj/content/libcontent_worker.a
obj/content/libcontent_app_both.a   
obj/third_party/WebKit/Source/platform/libblink_platform.a   
obj/third_party/ots/libots.a   
obj/third_party/WebKit/Source/web/libblink_web.a  
obj/third_party/WebKit/Source/core/libwebcore_remaining.a -Wl,--end-group
--verbose --save-temps


Why necessary, I will try to isolate the bunch of translation units.

Thanks,
Martin

[Bug ipa/63298] [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO

[tbsaunde at gcc dot gnu.org]

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

tbsaunde at gcc dot gnu.org changed:

   What|Removed |Added

 CC||tbsaunde at gcc dot gnu.org

--- Comment #1 from tbsaunde at gcc dot gnu.org ---
if it helps I see this when building TestFile in firefox (I gues you to not use
--disable-tests)

[Bug target/61360] [5 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4

[vmakarov at gcc dot gnu.org]

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

--- Comment #14 from Vladimir Makarov  ---
LRA reuses data about enabled alternatives (through code in recog.c) from
previous passes.  And the data are not right anymore.  There are two ways of
fixing that:

o enable the alternative with only "m" for LRA (remove lra_in_progress from the
definition of the attribute) as LRA can handle only "m" although reload can't.

o prevent reusing the data

I'll prepare and submit the patch for the second solution.  Although it would
be wise with perfomance point of view to implement the first one too but I
handle over this joba and the decision to x86 maintainers.

[Bug testsuite/63299] New: ASan reported alloc-dealloc-mismatch in g++.old-deja/g++.jason/init3.C

[chefmax at gcc dot gnu.org]

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

Bug ID: 63299
   Summary: ASan reported alloc-dealloc-mismatch in
g++.old-deja/g++.jason/init3.C
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chefmax at gcc dot gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 33513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33513&action=edit
This trivial patch seems to fix the issue.

ASan reported alloc-dealloc-mismatch in g++.old-deja/g++.jason/init3.C:

$ ~/install/master/bin/g++  gcc/testsuite/g++.old-deja/g++.jason/init3.C
-fsanitize=address

=
==26627==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new [] vs
operator delete) on 0x6020ef70
#0 0x7fca6b2ca6a9 in operator delete(void*)
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_new_delete.cc:85
#1 0x4015d1 in My_string::~My_string()
(/home/max/workspace/downloads/gcc/a.out+0x4015d1)
#2 0x4013e6 in main (/home/max/workspace/downloads/gcc/a.out+0x4013e6)
#3 0x7fca6a67c76c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#4 0x400d98 (/home/max/workspace/downloads/gcc/a.out+0x400d98)

0x6020ef70 is located 0 bytes inside of 13-byte region
[0x6020ef70,0x6020ef7d)
allocated by thread T0 here:
#0 0x7fca6b2ca2b9 in operator new[](unsigned long)
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_new_delete.cc:55
#1 0x40118d in My_string::My_string(My_string const&)
(/home/max/workspace/downloads/gcc/a.out+0x40118d)
#2 0x4013b8 in main (/home/max/workspace/downloads/gcc/a.out+0x4013b8)
#3 0x7fca6a67c76c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)

SUMMARY: AddressSanitizer: alloc-dealloc-mismatch
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_new_delete.cc:85
operator delete(void*)
==26627==HINT: if you don't care about these warnings you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==26627==ABORTING

[Bug target/61360] [5 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4

[vmakarov at gcc dot gnu.org]

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

--- Comment #15 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Sep 18 15:57:06 2014
New Revision: 215358

URL: https://gcc.gnu.org/viewcvs?rev=215358&root=gcc&view=rev
Log:
2014-09-18  Vladimir Makarov  

PR target/61360
* lra.c (lra): Call recog_init.

2014-09-18  Vladimir Makarov  

PR target/61360
* gcc.target/i386/pr61360.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr61360.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/63300] New: 'const volatile' sometimes stripped in debug info

[arnez at linux dot vnet.ibm.com]

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

Bug ID: 63300
   Summary: 'const volatile' sometimes stripped in debug info
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnez at linux dot vnet.ibm.com

With current upstream gcc, the following commands do not yield the expected
output:

echo 'void f (const volatile int x) { }' | gcc -xc -c -g -o foo.o -
readelf -wi foo.o | grep 'volatile\|const'

With an older gcc we get something like this:

 <1><54>: Abbrev Number: 4 (DW_TAG_const_type)
 <1><59>: Abbrev Number: 5 (DW_TAG_volatile_type)

With the current gcc we get nothing.  Indeed, the resulting debug info declares
the parameter 'x' merely as an 'int' instead of 'const volatile int'.

The same happens with some other combinations as well, e.g.:

char *const volatile x
const volatile float x
const volatile int *x

[Bug c++/63248] Crash when OpenMP target's array section handling is used with templates

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 18 16:43:28 2014
New Revision: 215359

URL: https://gcc.gnu.org/viewcvs?rev=215359&root=gcc&view=rev
Log:
PR c++/63248
* semantics.c (finish_omp_clauses): Don't call cp_omp_mappable_type
on type of type dependent expressions, and don't call it if
handle_omp_array_sections has kept TREE_LIST because something
was type dependent.
* pt.c (tsubst_expr) :
Use keep_next_level, begin_omp_structured_block and
finish_omp_structured_block instead of push_stmt_list and
pop_stmt_list.
libgomp/
* testsuite/libgomp.c++/pr63248.C: New test.

Added:
trunk/libgomp/testsuite/libgomp.c++/pr63248.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/libgomp/ChangeLog

[Bug c++/63248] Crash when OpenMP target's array section handling is used with templates

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Sep 18 16:46:17 2014
New Revision: 215360

URL: https://gcc.gnu.org/viewcvs?rev=215360&root=gcc&view=rev
Log:
PR c++/63248
* semantics.c (finish_omp_clauses): Don't call cp_omp_mappable_type
on type of type dependent expressions, and don't call it if
handle_omp_array_sections has kept TREE_LIST because something
was type dependent.
* pt.c (tsubst_expr) :
Use keep_next_level, begin_omp_structured_block and
finish_omp_structured_block instead of push_stmt_list and
pop_stmt_list.
libgomp/
* testsuite/libgomp.c++/pr63248.C: New test.

Added:
branches/gcc-4_9-branch/libgomp/testsuite/libgomp.c++/pr63248.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/pt.c
branches/gcc-4_9-branch/gcc/cp/semantics.c
branches/gcc-4_9-branch/libgomp/ChangeLog

[Bug middle-end/63279] [5 Regression] Processes hang inside Linux Kernel built with gcc5

[sasha.levin at oracle dot com]

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

Sasha Levin  changed:

   What|Removed |Added

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

--- Comment #6 from Sasha Levin  ---
The fix from PR61848 seems to have done the trick. Thanks!

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

[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost

[sasha.levin at oracle dot com]

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

Sasha Levin  changed:

   What|Removed |Added

 CC||sasha.levin at oracle dot com

--- Comment #13 from Sasha Levin  ---
*** Bug 63279 has been marked as a duplicate of this bug. ***

[Bug debug/63285] [4.9/5 Regression] -fcompare-debug scheduler related failure

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
it is a bit different situation from PR61923: debug insns after the asm.

I'll submit the patch today.

[Bug c++/63248] Crash when OpenMP target's array section handling is used with templates

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.2

--- Comment #3 from Jakub Jelinek  ---
Should be fixed now.

[Bug c++/63249] [OpenMP] Spurious »set but not used« warnings when actually used in OpenMP target's array section's lower-bound and length

[jakub at gcc dot gnu.org]

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

Bug 63248 Summary: Crash when OpenMP target's array section handling is used 
with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63248

   What|Removed |Added

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

[Bug target/56993] power gcc built 416.gamess generates wrong result

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #5)
>   common /a/ i(10)
> subroutine foo (j)
>   common /a/ i(1)
> Is that valid Fortran at all?

No. Fortran 2008 (in 5.7.2.5) has: "Named common blocks of the same name shall
be of the same size in all scoping units of a program in which they appear"

That's not new as FORTRAN 77 (in 8.3.3) had: "Within an executable program, all
named common blocks that have the same name must be the same size".

The example has a named common block with name "A". Admittedly, that's not
really the issue for the wrong code here - as one could simply turn it into a
blank common: "but blocks of the same name shall be of the same size in at
blank common blocks may be of different sizes." [continuation of F2008 quote].


>   call foo (10)
> end
> subroutine foo (j)
>   common /a/ i(1)
...
>   do k = 1, j
> l = l + i(k)
>
> Is that valid Fortran at all? 

In terms of the standard: No. Fortran 2008 explicitly states: "The value of a
subscript in an array element shall be within the bounds for its dimension."
(F2008, 6.5.3.)

For Fortran 77, I could only find something less explicit: "The first  element 
of  the  array has a subscript value of one; the second element has a subscript
value  of  two; the  last  element  has  a subscript value equal to the size of
the array." and "The size of an array is equal to the  product  of  the  sizes 
of  the dimensions  specified  by the array declarator for that array name."

Hence, I'd claim that anything but 1 is already invalid in Fortran 77. (Storage
associations in general allows some tricks, such as with using EQUIVALENCE (cf.
C/C++'s union) but this does not apply here.)


In Fortran 66/77, it was alledgedly not uncommon to write "dimension(1)" for
dummy/formal arguments - instead of using dimension(*) - and then to access
array elements beyond the first one. (Also invalid back then.) However, for
COMMON, that's new to me. (Not that I have much experience with pre-Fortran-90
code.)


> If Fortran as language allows this, either everywhere, or for compatibility
> in some mode, it would be better if such common blocks were modeled similarly
> to C99 flexible array members with GNU extension of initializing that;

Hmm, the big problem is where to draw a boundary and what to support. As such
things were never allowed by the standard, it is difficult to decide what to
support and using which flag. In real-world code, one can find tons of code
which was invalid but worked - often for years and with different compilers -
until it suddenly stopped doing so. It seems as if GCC/gfortran is in
particular successful in doing so (judging from bug reports) - which implies
that it seems to be better at exploiting optimization opportunities given by
the language.

A similar use to the one above would be:

integer A
integer B
COMMON /foo/ A(5), B(7)

and accessing A(8). That memory reference matches B(3) and is a valid memory
address. (Fortran's storage association rules guarantee this.) Still, it
exceeds "A" and is hence invalid according to the Fortran standard - and I
assume also the middle end does not like A(8).

I think for that memory access, the VLA trick wouldn't work. I try to avoid
such legacy extensions as they are ill-defined.


In any case, gfortran with -fcheck=bounds should reject this at run time - and
using a compile-time array index it should do so already at compile time. 


> From the comments in unport.F, it looks like 416.gamess has commented out
> even far uglier hacks, in particular using the COMMON /FPCOM / X(1) and then
> when accessing it biasing index by some variable, which is initialized as a
> difference between a heap region and the array in the common block.  That
> would be even worse for the middle-end and C semantics, dunno what Fortran
> as language ever allowed and what needs to be (optionally?) tolerated to get
> badly written code working.

Well, I think in may cases, the early versions of the language - like the
Fortran manuals from IBM - simply didn't state what would happen in that case.
But back in the old days, for many the standard matched what their compiler
did.

For instance a loop like "do i = 5, 3": How often is it executed? (Fortran 66
didn't permit it - but one can still write it.) Answer: With some vendors once,
with other vendors zero times. I think already Fortran 77 standardized this to
execute zero times. As the execute-once version was common, several compilers
(including Intel's current one, g77 and others) had a compile-time flag to
permit this.

(Actually, if I look at the code gfortran generates for a loop, it is written
such that once-trip loops could be simply enabled, even though no flag exists
to turn it on.)


(In reply to Vladimir Makarov from comment #6)
> Some SPEC benchmarks contain questionable code.  It is true for SPEC2000
> and true for SPEC2006.  So the PR is not a surprise for me.
> 
> 

[Bug c++/61465] Bogus parameter set but not used warning in constructor initialization list

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-09-18
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c/63301] New: inconsistency on wchar_t and wint_t types and sizes for diverse architectures

[marcos.diaz at tallertechnologies dot com]

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

Bug ID: 63301
   Summary: inconsistency on wchar_t and wint_t types and sizes
for diverse architectures
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcos.diaz at tallertechnologies dot com

Created attachment 33514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33514&action=edit
Test to print wchar_t

At compiling the attached file with the following command:
sparc-rtems4.11-gcc testw_char.c -Wall -Wextra -c

The following warning appeared:

testw_char.c: In function 'main':
testw_char.c:6:2: warning: format '%lc' expects argument of type 'wint_t', but
argument 2 has type 'wchar_t' [-Wformat=]
  printf("%lc", wc);
  ^
testw_char.c:6:2: warning: format '%lc' expects argument of type 'wint_t', but
argument 2 has type 'wchar_t' [-Wformat=]

But if we compile the same file with, for example, arm-rtems4.11-gcc we get no
warning.

At further investigation we saw that the types of the wint_t and wchar_t for
this architecture were different:

 sparc-rtems4.11-gcc testw_char.c -Wall -Wextra -c -E

The output is as follows:
...
typedef long int wchar_t;
typedef unsigned int wint_t;
...

(Note that the type of wchar_t is larger than of wint_t)

With help from Joel Sherrill in RTEMS we could see that those architectures
that issue the warning have inconsistency in the types of wint_t and wchar_t,
and the others dont:

=== arm-rtems4.11-gcc - no warning

typedef unsigned int wchar_t;
typedef unsigned int wint_t;

(this has no warnings).

These are the others that Joel detected with the inconsistency:

=== m68k-rtems4.11-gcc

typedef long int wchar_t;
typedef unsigned int wint_t;

=== m32c-rtems4.11-gcc - warning

typedef long int wchar_t;
typedef unsigned int wint_t;

=== powerpc-rtems4.11-gcc - warning

typedef long int wchar_t;
typedef unsigned int wint_t;

=== sh-rtems4.11-gcc - warning

typedef long int wchar_t;
typedef unsigned int wint_t;

=== sparc-rtems4.11-gcc - warning

typedef long int wchar_t;
typedef unsigned int wint_t;

=== v850-rtems4.11-gcc - warning

typedef long int wchar_t;
typedef unsigned int wint_t;


The configuration for sparc-rtems4.11-gcc: (the others are similar)

Using built-in specs.
COLLECT_GCC=sparc-rtems4.11-gcc
COLLECT_LTO_WRAPPER=/home/marcos/Desktop/WcharRTEMS/ins-gcc/libexec/gcc/sparc-rtems4.11/4.8.3/lto-wrapper
Target: sparc-rtems4.11
Configured with: ../gcc-4.8.3/configure --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=sparc-rtems4.11 --disable-libstdcxx-pch
--with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-languages=c,c++

[Bug ipa/63298] [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-18
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jan Hubicka  ---
It seems I made typo here:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 215363)
+++ ipa-devirt.c(working copy)
@@ -526,7 +526,7 @@
 return false;

   /* For ODR types be sure to compare their names.  */
-  if ((odr_type_p (t1) && !odr_type_p (t2))
+  if ((odr_type_p (t1) && odr_type_p (t2))
   || (TREE_CODE (t1) == RECORD_TYPE && TREE_CODE (t2) == RECORD_TYPE
   && TYPE_BINFO (t1) && TYPE_BINFO (t2)
   && polymorphic_type_binfo_p (TYPE_BINFO (t1))

(I was negating this conditional about 5 times ;).
Does it fix the problem?

[Bug debug/63285] [4.9/5 Regression] -fcompare-debug scheduler related failure

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Sep 18 19:14:19 2014
New Revision: 215364

URL: https://gcc.gnu.org/viewcvs?rev=215364&root=gcc&view=rev
Log:
2014-09-18  Vladimir Makarov  

PR debug/63285
* haifa-sched.c (schedule_block): Advance cycle at the end of BB
if advance != 0.

2014-09-18  Vladimir Makarov  

PR debug/63285
* gcc.target/i386/pr63285.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr63285.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/63298] [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO

[mliska at suse dot cz]

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

--- Comment #3 from Martin Liška  ---
Works for me ;)

[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
#include 
__m128d f(){
  __m128d r;
  r[0]=1;
  r[1]=2;
  return r;
}

Currently, SLP vectorizes it with -fvect-cost-model=unlimited, but not by
default because:

  Vector inside of basic block cost: 1
  Vector prologue cost: 1
  Vector epilogue cost: 0
  Scalar cost of basic block: 2
r.c:4:9: note: not vectorized: vectorization is not profitable.

And if r is initialized to {3,4} as in the initial testcase, we don't vectorize
either:

r.c:3:17: note: not vectorized: no vectype for stmt: # .MEM_2 = VDEF
<.MEM_1(D)>
rD.15637 = { 3.0e+0, 4.0e+0 };
 scalar_type: __m128dD.4386
r.c:3:17: note: not vectorized: not enough data-refs in basic block.

[Bug fortran/63294] ICE allocattion of array of type of type

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-09-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
A test case showing the problem is missing.

[Bug ipa/61916] Internal compiler error in symtab_nonoverwritable_alias with -O2

[timothygu99 at gmail dot com]

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

--- Comment #4 from Timothy Gu  ---
Any news on this?

[Bug ipa/61916] Internal compiler error in symtab_nonoverwritable_alias with -O2

[timothygu99 at gmail dot com]

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

--- Comment #5 from Timothy Gu  ---
I have found another file that triggers this:

# i686-pc-mingw32.static-gcc -v -save-temps -O2 tclsqlite.c
Using built-in specs.
COLLECT_GCC=i686-pc-mingw32.static-gcc
COLLECT_LTO_WRAPPER=/root/Timothys_sandbox/mxe/usr/libexec/gcc/i686-pc-mingw32.static/4.9.1/lto-wrapper
Target: i686-pc-mingw32.static
Configured with:
/root/Timothys_sandbox/mxe/tmp-gcc-i686-pc-mingw32.static/gcc-4.9.1/configure
--target=i686-pc-mingw32.static --build=x86_64-unknown-linux-gnu
--prefix=/root/Timothys_sandbox/mxe/usr
--libdir=/root/Timothys_sandbox/mxe/usr/lib
--enable-languages=c,c++,objc,fortran --enable-version-specific-runtime-libs
--with-gcc --with-gnu-ld --with-gnu-as --disable-nls --disable-shared
--disable-multilib --without-x --disable-win32-registry --enable-threads=win32
--disable-libgomp --with-cloog=/root/Timothys_sandbox/mxe/usr
--with-gmp=/root/Timothys_sandbox/mxe/usr
--with-isl=/root/Timothys_sandbox/mxe/usr
--with-mpc=/root/Timothys_sandbox/mxe/usr
--with-mpfr=/root/Timothys_sandbox/mxe/usr
--with-as=/root/Timothys_sandbox/mxe/usr/bin/i686-pc-mingw32.static-as
--with-ld=/root/Timothys_sandbox/mxe/usr/bin/i686-pc-mingw32.static-ld
--with-nm=/root/Timothys_sandbox/mxe/usr/bin/i686-pc-mingw32.static-nm
--disable-sjlj-exceptions
Thread model: win32
gcc version 4.9.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-mtune=generic'
'-march=pentiumpro'
 /root/Timothys_sandbox/mxe/usr/libexec/gcc/i686-pc-mingw32.static/4.9.1/cc1 -E
-quiet -v tclsqlite.c -mtune=generic -march=pentiumpro -O2 -fpch-preprocess -o
tclsqlite.i
ignoring nonexistent directory
"/root/Timothys_sandbox/mxe/usr/lib/gcc/i686-pc-mingw32.static/4.9.1/../../../../i686-pc-mingw32.static/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /root/Timothys_sandbox/mxe/usr/lib/gcc/i686-pc-mingw32.static/4.9.1/include

/root/Timothys_sandbox/mxe/usr/lib/gcc/i686-pc-mingw32.static/4.9.1/include-fixed

/root/Timothys_sandbox/mxe/usr/lib/gcc/i686-pc-mingw32.static/4.9.1/../../../../i686-pc-mingw32.static/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-mtune=generic'
'-march=pentiumpro'
 /root/Timothys_sandbox/mxe/usr/libexec/gcc/i686-pc-mingw32.static/4.9.1/cc1
-fpreprocessed tclsqlite.i -quiet -dumpbase tclsqlite.c -mtune=generic
-march=pentiumpro -auxbase tclsqlite -O2 -version -o tclsqlite.s
GNU C (GCC) version 4.9.1 (i686-pc-mingw32.static)
compiled by GNU C version 4.8.1, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.9.1 (i686-pc-mingw32.static)
compiled by GNU C version 4.8.1, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 95b02311e7569b5d473f7ceccfa71955
../pkgs/sqlite3.8.0/generic/tclsqlite3.c:3109:1: internal compiler error: in
symtab_nonoverwritable_alias, at symtab.c:1252
0x65b414 symtab_nonoverwritable_alias(symtab_node*)
   
/root/Timothys_sandbox/mxe/tmp-gcc-i686-pc-mingw32.static/gcc-4.9.1/gcc/symtab.c:1252
0x7a0081 function_and_variable_visibility
   
/root/Timothys_sandbox/mxe/tmp-gcc-i686-pc-mingw32.static/gcc-4.9.1/gcc/ipa.c:1101
0x7a0826 whole_program_function_and_variable_visibility
   
/root/Timothys_sandbox/mxe/tmp-gcc-i686-pc-mingw32.static/gcc-4.9.1/gcc/ipa.c:1306
0x7a0826 execute
   
/root/Timothys_sandbox/mxe/tmp-gcc-i686-pc-mingw32.static/gcc-4.9.1/gcc/ipa.c:1350
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This file comes from tcl8.6.1/pkgs/sqlite3.8.0/generic/tclsqlite3.c.

Again, this is not reproducible with -O1, therefore it is an optimizer problem.

[Bug tree-optimization/63302] New: [4.9,5.0 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host

[danglin at gcc dot gnu.org]

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

Bug ID: 63302
   Summary: [4.9,5.0 Regression] Code with 64-bit long long
constants is miscompiled on 32-bit host
   Product: gcc
   Version: 4.9.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: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

The following function from pa.c is miscompiled when generating a hppa64
cross compiler:

dave@mx3210:~/hardware/ldil$ cat ldil.c
#define HOST_WIDE_INT long long
int
pa_ldil_cint_p (HOST_WIDE_INT ival)
{
 HOST_WIDE_INT x = ival & (((HOST_WIDE_INT) -1 << 31) | 0x7ff);

 return x == 0 || x == ((HOST_WIDE_INT) -1 << 31);
}

gcc-4.9 -S -O1 ldil.c:

dave@mx3210:~/hardware/ldil$ cat ldil.s
.LEVEL 1.1
.text
.align 4
.globl pa_ldil_cint_p
.typepa_ldil_cint_p, @function
pa_ldil_cint_p:
.PROC
.CALLINFO FRAME=0,NO_CALLS
.ENTRY
extru %r26,31,11,%r28
comiclr,<> 0,%r28,%r28
ldi 1,%r28
bv,n %r0(%r2)
.EXIT
.PROCEND
.sizepa_ldil_cint_p, .-pa_ldil_cint_p
.ident"GCC: (Debian 4.9.1-14) 4.9.1"

The high order bits are not checked in the assembly code.  We have the
following in ldil.c.170r.expand:

pa_ldil_cint_p (long long int ival)
{
  int _6;
  long long int _8;
  _Bool _9;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _8 = ival_1(D) & 2047;
  _9 = _8 == 0;
  _6 = (int) _9;
  return _6;
;;succ:   EXIT

}

This breaks 64-bit kernel build.  4.8 branch is ok.

[Bug c/63303] New: Pointer subtraction is broken when using -fsanitize=undefined

[mikulas at artax dot karlin.mff.cuni.cz]

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

Bug ID: 63303
   Summary: Pointer subtraction is broken when using
-fsanitize=undefined
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Host: x86_64-linux-gnux32
Target: x86_64-linux-gnux32
 Build: x86_64-linux-gnux32

The undefined behavior sanitizer incorrectly warns about pointer subtraction.

The reason is that the undefined behavior sanitizer treats pointer subtraction
like subtraction of two signed integers and warns if it would result in integer
overflow. However, this logic is incorrect.

Subtracting of these two pointers is perfectly legal operation but it results
in incorrect warning: (char *)0x9000 - (char *)0x7000: this bug causes
spurious warnings in correct program if array spans the boundary 0x8000 and
the program subtracts pointers in this array.

Subtracting these two pointers doesn't result in a warning, but it should
because the resulting integer overflows: (char *)0xc000 - (char
*)0x3000

BTW. The sanitizer also lacks warnings when addition of a pointer and integer
results in overflow. For example (char *)0xd000 + 0x4000U doesn't
result in a warning but it should.

This is the example code, compile it with -fsanitize=undefined

#include 
#include 

__attribute((noinline,noclone)) ptrdiff_t ptr_diff(char *p1, char *p2)
{
return p1 - p2;
}

__attribute((noinline,noclone)) void *ptr_add(char *p1, unsigned long p2)
{
return p1 + p2;
}

void *get_address(unsigned n)
{
return (void *)((unsigned long)n << (sizeof(void *) * 8 - 4));
}

int main(void)
{
printf("%ld\n", (long)ptr_diff(get_address(0x9), get_address(0x7))); /*
sanitizer should not warn here */
printf("%ld\n", (long)ptr_diff(get_address(0xc), get_address(0x3))); /*
sanitizer should warn here */
return 0;
}

[Bug ipa/63298] [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Author: hubicka
Date: Fri Sep 19 02:04:20 2014
New Revision: 215374

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

PR lto/63298
* ipa-devirt.c (odr_subtypes_equivalent_p): Fix thinko in a condition.

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

[Bug target/63304] New: Aarch64 pc-relative load offset out of range

[venkataramanan.kumar at amd dot com]

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

Bug ID: 63304
   Summary: Aarch64 pc-relative load offset out of range
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: venkataramanan.kumar at amd dot com

Constant literal table is kept at large offset, resulting in pc-relative load
offset out of range.

aarch64-none-linux-gnu-gcc x.c 
/tmp/ccrOQLEb.s: Assembler messages:
/tmp/ccrOQLEb.s:10: Error: pc-relative load offset out of range

[Bug target/63304] Aarch64 pc-relative load offset out of range

[venkataramanan.kumar at amd dot com]

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

--- Comment #1 from Venkataramanan  ---
Created attachment 33515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33515&action=edit
Attached test case

[Bug target/63304] Aarch64 pc-relative load offset out of range

[venkataramanan.kumar at amd dot com]

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

--- Comment #2 from Venkataramanan  ---
Marcus, can you please assign it to me if it is confirmed.

[Bug testsuite/63305] New: ASan reported heap-buffer-overflow in gcc.target/i386/avx256-unaligned-load{store}-7.c

[chefmax at gcc dot gnu.org]

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

Bug ID: 63305
   Summary: ASan reported heap-buffer-overflow in
gcc.target/i386/avx256-unaligned-load{store}-7.c
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chefmax at gcc dot gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

ASan reported heap-buffer-overflow in
gcc.target/i386/avx256-unaligned-load{store}-7.c:

$ ~/master/gcc gcc/testsuite/gcc.target/i386/avx256-unaligned-load-7.c 
-fsanitize=address -O3 -dp -mavx -mavx256-split-unaligned-load -o
./avx256-unaligned-load-7.exe

$ ./avx256-unaligned-load-7.exe


=
==21855==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60c0c000 at pc 0x400bcc bp 0x7fffd03d3d90 sp 0x7fffd03d3d88
WRITE of size 8 at 0x60c0c000 thread T0
#0 0x400bcb in do_test
(/home/max/build/master-x86_64/avx256-unaligned-load-7.exe+0x400bcb)
#1 0x40086f in main
(/home/max/build/master-x86_64/avx256-unaligned-load-7.exe+0x40086f)
#2 0x7fecbc89476c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#3 0x4008c4
(/home/max/build/master-x86_64/avx256-unaligned-load-7.exe+0x4008c4)

0x60c0c000 is located 0 bytes to the right of 128-byte region
[0x60c0bf80,0x60c0c000)
allocated by thread T0 here:
#0 0x7fecbccc5569 in __interceptor_malloc
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_malloc_linux.cc:73
#1 0x4009bd in foo
(/home/max/build/master-x86_64/avx256-unaligned-load-7.exe+0x4009bd)

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 do_test
Shadow bytes around the buggy address:
  0x0c187fff97b0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c187fff97c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c187fff97d0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c187fff97e0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c187fff97f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c187fff9800:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c187fff9850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  ASan internal:   fe
==21855==ABORTING

Quick analysis shows that overflow happens at line 38. Perhaps allocated arrays
have wrong size.