[Bug c++/60384] [4.9 Regression] [c++1y] ICE with invalid typedef

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60384

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r199779.

[Bug c++/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
It uses the DWARF ABI register number mapping for .debug_frame and a slightly
different one for .eh_frame.

[Bug objc++/60398] New: [4.9 Regression] FAIL: obj-c++.dg/invalid-method-2.mm -fgnu-runtime (test for errors, line 10)

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60398

Bug ID: 60398
   Summary: [4.9 Regression] FAIL: obj-c++.dg/invalid-method-2.mm
-fgnu-runtime  (test for errors, line 10)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com

Recent regression in obj-c++ testsuite [1]:

FAIL: obj-c++.dg/invalid-method-2.mm -fgnu-runtime  (test for errors, line 10)
FAIL: obj-c++.dg/invalid-method-2.mm -fgnu-runtime  (test for errors, line 14)
FAIL: obj-c++.dg/invalid-method-2.mm -fgnu-runtime (test for excess errors)

Compiler version: 4.9.0 20140228 (experimental) [trunk revision 208223] (GCC) 

[1] http://gcc.gnu.org/ml/gcc-testresults/2014-03/msg00166.html

The compiler generates different warnings:

output is:
/home/uros/gcc-svn/trunk/gcc/testsuite/obj-c++.dg/invalid-method-2.mm:10:4:
error: 'x' does not name a type^M
/home/uros/gcc-svn/trunk/gcc/testsuite/obj-c++.dg/invalid-method-2.mm:14:18:
error: 'x' does not name a type^M

while the testcase in both cases expects:

/* { dg-error "expected" } */

[Bug ipa/60243] IPA is slow on large cgraph tree

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243

--- Comment #12 from rguenther at suse dot de  ---
On Sun, 2 Mar 2014, hubicka at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
> 
> --- Comment #11 from Jan Hubicka  ---
> Created attachment 32244
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32244&action=edit
> WIP patch
> 
> this patch cuts some redundant work on estimating size of functions that will
> be too large to be inlined anyway. Currently inliner spends a lot of time
> compuing properties of these functions (since small and inlinable functions 
> are
> also fast to estimate)
> 
> The patch doesn't really save much time building libreoffice/firefox. I will
> experiment with it a bit more.

Does it help PR60315?  That one is even more an excessive example.

[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
Confirmed with 4.6 to trunk.

Somewhat modified test case (using integers, 2x2 matrices, functions; without
random numbers):


program test
  implicit none

  integer, dimension(2,2), parameter :: A = reshape ((/1,2,3,4/), (/2,2/))
  integer, dimension(2,2) :: B1, B2

  ! Normal argument
  B1 = my_mul(A,A)
  B2 = my_mul_cont(A,A)
  print *,'Normal:',maxval(abs(B1-B2))
  print *,B1
  print *,B2

  ! Transposed argument
  B1 = my_mul(transpose(A),A)
  B2 = my_mul_cont(transpose(A),A)
  print *,'Transposed:',maxval(abs(B1-B2))
  print *,B1
  print *,B2

contains

  function my_mul(A,C) result (B)
use, intrinsic :: ISO_Fortran_env
integer, intent(in) :: A(2,2), C(2,2)
integer :: B(2,2)
B = matmul(A, C)
  end function

  function my_mul_cont(A,C) result (B)
use, intrinsic :: ISO_Fortran_env
integer, intent(in), contiguous :: A(:,:), C(:,:)
integer :: B(2,2)
B = matmul(A, C)
  end function

end program

[Bug c++/60383] [4.9 Regression] ICE with invalid template specialization

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60383

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
Summary|[4.8 Regression] ICE with   |[4.9 Regression] ICE with
   |invalid template|invalid template
   |specialization  |specialization

[Bug tree-optimization/60382] [4.8/4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu (in vect_create_epilog_for_reduction, at tree-vect-loop.c:4352)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60382

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Mine.

[Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.9.0

[Bug c++/60379] [4.9 Regression] pugixml build failure caused by r207001

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60379

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c++/60374] [4.7/4.8/4.9 Regression] [c++11] ICE with invalid template specialization

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60374

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/60375] [4.9 Regression] [c++11] ICE with invalid use of lambda

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60375

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/60376] [4.9 Regression] [c++1y] ICE using member function in a template function

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60376

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/60389] [4.8/4.9 Regression] [c++11] ICE with inheriting constructors and wrong usage of constexpr

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60389

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P5

[Bug c++/60386] [C++11][NSDMI] Crash on a template class containing array initialized in-class

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60386

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-03
Summary|[C++11] Crash on a template |[C++11][NSDMI] Crash on a
   |class containing array  |template class containing
   |initialized in-class|array initialized in-class
 Ever confirmed|0   |1
  Known to fail||4.7.2, 4.8.2, 4.9.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c++/60385] confused by earlier errors, bailing out

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60385

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-03
 Ever confirmed|0   |1
  Known to fail||4.7.3, 4.8.2, 4.9.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug objc++/60398] [4.9 Regression] FAIL: obj-c++.dg/invalid-method-2.mm -fgnu-runtime (test for errors, line 10)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60398

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-03
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c++/60376] [4.9 Regression] [c++1y] ICE using member function in a template function

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60376

Paolo Carlini  changed:

   What|Removed |Added

   Priority|P1  |P3

--- Comment #3 from Paolo Carlini  ---
Please file a separate bug report, it's a different issue.

[Bug objc++/60398] [4.9 Regression] FAIL: obj-c++.dg/invalid-method-2.mm -fgnu-runtime (test for errors, line 10)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60398

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Looks like this is caused by r208040, I'll just adjust the testcase, similarly
how the C++ testcases have been adjusted.

[Bug lto/60395] LTO link fails when -fno-builtin is specified

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60395

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-03
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.7.2, 4.8.2, 4.9.0

--- Comment #4 from Richard Biener  ---
Confirmed on x86_64 with using -mstringop-strategy=libcall.  Shorter
single-file testcase:

void *memset(void *dest, int ch, __SIZE_TYPE__ count)
{
  char *p = (char *)dest;

  while (count--)
*p++ = (char)ch;
  return dest;
}
int main ()
{
  volatile int dummy[10] = {0};
  return dummy[0];
}

> gcc t.c -Os -mstringop-strategy=libcall -flto -fno-builtin
`memset' referenced in section `.text.startup' of
/tmp/ccdDUr5m.ltrans0.ltrans.o: defined in discarded section `.text' of
/tmp/ccApnJzK.o (symbol from plugin)
collect2: error: ld returned 1 exit status

1
t.o 2
177 b0e6a56d4c94b3b5 PREVAILING_DEF_IRONLY memset
180 b0e6a56d4c94b3b5 PREVAILING_DEF main

and then IPA kills the memset definition because it's unused at IPA time
and it isn't a builtin.  Then expansion re-introduces a call to memset
an we use the linker resolution and try to bind it locally which obviously
fails (even though a fallback is available in libc).

IMHO even with -fno-builtin IPA needs to preserve certain function bodies
we may introduce calls to late (memset, memcpy, memmove are the obvious
ones), much like we have special_function_p which matches on the function
name and not only the builtin property.  Or we need to simply _not_ mark
those definitons as non-builtin as we introduce calls to them late.  Or
we need to fixup things at the linker side (we introduce a call to the
_builtin_ memset but we discarded a non-builtin memset).

The special_function_p-like hack is probably easiest but not the robustest
solution.  Not sure if we can adjust the linkers idea of where a def resides
at all.

Honza?

[Bug lto/60395] LTO link fails when -fno-builtin is specified

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60395

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
This isn't just about builtins, but any library calls introduced after IPA.
E.g. -mveclibabi= calls come to my mind, if you define those functions in your
library/binary and link with -flto, you'll probably get the same problem.

[Bug objc++/60398] [4.9 Regression] FAIL: obj-c++.dg/invalid-method-2.mm -fgnu-runtime (test for errors, line 10)

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60398

--- Comment #3 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #2)
> Looks like this is caused by r208040, ...

There was no testsuite ChangeLog entry, I *did* look for recent testsuite
changes.

[Bug objc++/60398] [4.9 Regression] FAIL: obj-c++.dg/invalid-method-2.mm -fgnu-runtime (test for errors, line 10)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60398

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar  3 09:36:44 2014
New Revision: 208270

URL: http://gcc.gnu.org/viewcvs?rev=208270&root=gcc&view=rev
Log:
PR objc++/60398
* obj-c++.dg/invalid-method-2.mm: Adjust dg-error regexps.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/invalid-method-2.mm

[Bug objc++/60398] [4.9 Regression] FAIL: obj-c++.dg/invalid-method-2.mm -fgnu-runtime (test for errors, line 10)

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60398

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/60396] Missing time_get<>::get() functions

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60396

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #1 from Jonathan Wakely  ---
Yes, this is documented as not implemented yet.
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011

[Bug c++/60361] [4.7/4.8/4.9 Regression] unexpected 'use of parameter outside function body' error

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-03
  Known to work||4.3.5
Summary|unexpected 'use of  |[4.7/4.8/4.9 Regression]
   |parameter outside function  |unexpected 'use of
   |body' error |parameter outside function
   ||body' error
 Ever confirmed|0   |1
  Known to fail||4.6.2, 4.7.4, 4.8.2, 4.9.0

--- Comment #1 from Jonathan Wakely  ---
4.4 and 4.5 say:

t.cc:18:34: error: 'A' cannot appear in a constant-expression
t.cc:18:36: error: no matching function for call to 'Helper::Helper(int,
)'
t.cc:3:3: note: candidates are: Helper::Helper(int, void (*)())
t.cc:2:1: note: Helper::Helper(const Helper&)

and 4.6 onwards give the "use of parameter 'A' outside function body" error, so
if the code is valid this is a regression.

[Bug tree-optimization/54779] split FRAME variables back into pieces

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54779

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #28323|0   |1
is obsolete||

--- Comment #6 from Eric Botcazou  ---
Created attachment 32249
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32249&action=edit
Updated implementation

* gimple.c (gimple_ior_addresses_taken_1): Handle non-local frame
structures specially.
* tree-ssa.c (get_base_of_component_ref): New static function.
(lookup_decl_for_field): Likewise.
(split_nonlocal_frames_op): Likewise.
(execute_update_addresses_taken): Break up non-local frame structures
into variables when possible.

[Bug tree-optimization/54779] split FRAME variables back into pieces

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54779

--- Comment #7 from Eric Botcazou  ---
Results (ms) for SPARKSkein on x86-64 at -O3 -gnatn -gnatp:

Before:
DT_Min is  36
Minis15.21
Median is15.22

After:
DT_Min is  36
Minis14.56
Median is14.58

[Bug c++/60399] New: constexpr ctor that does not init an attribute should be rejected but isn't

[wouter at voti dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60399

Bug ID: 60399
   Summary: constexpr ctor that does not init an attribute should
be rejected but isn't
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wouter at voti dot nl

Created attachment 32250
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32250&action=edit
cpp stanalone main file that shows the problem

AFAIK A constexpr constructor that does not initialize all attributes should be
rejected. In the attached code, which is accepted by the compiler, such a
constructor is invoked in the initialization of a static class attribute.

To my surprise the compiler generates an init_array entry for this (which is
what triggered me to dig into this, I work with a linkerscript that does not
allow any int_array entries). The generated entry is basically empty, just

static done = false;
if( ! done ){
   done = true;
}

When I make the constexpr constructor initialize the attribute the init_array
entry is gone.

I use GCC for ARM, 4.8.3

"C:/Program Files (x86)/GNU Tools ARM Embedded/4.8
2013q4/bin/arm-none-eabi-g++" -nostartfiles  -mcpu=cortex-m0 -mthumb
-fomit-frame-pointer -march=armv6-m -Wall -Werror -Wno-unused-local-typedefs
-Wno-maybe-uninitialized -fdata-sections -ffunction-sections -Os -fno-rtti
-fno-exceptions  -fno-threadsafe-statics -fno-use-cxa-get-exception-ptr
-std=c++11 -c -o main.o main.cpp

[Bug c++/60367] Default argument object is not getting constructed

[rob.desbois at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367

--- Comment #4 from rob.desbois at gmail dot com ---
The problem only seems to occur when using the pattern "= {}" to default the
parameter; "= foo{}" and "= foo()" don't seem to provoke the differing
addresses.

I have confirmed that member data set in the default constructor seems to be
correct in the temporary despite it being at an 'unconstructed' address. The
address of the 'unconstructed' temporary is consistently the size of the
nearest whole word to sizeof(foo) below the actually-constructed address, so it
seems the address isn't just random but possibly correct in itself.

It seems that the copy/move constructor has been replaced by a memcpy(), thus
losing the side-effects. I didn't state earlier but should confirm: this occurs
with "-O0" turning off optimizations.

Behaviour with clang (3.3 final) is as expected.

[Bug preprocessor/60400] New: ICE with trigraphs

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60400

Bug ID: 60400
   Summary: ICE with trigraphs
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org

r200376 fixed on the trunk ICE that can be still reproduced on the branch.

[Bug preprocessor/60400] ICE with trigraphs

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60400

--- Comment #1 from Jakub Jelinek  ---
Created attachment 32251
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32251&action=edit
gcc48-pr60400-test.patch

Testcase.

[Bug preprocessor/60400] [4.7/4.8 Regression] ICE with trigraphs

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60400

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-03
 CC||dehao at gcc dot gnu.org
Version|4.8.3   |4.7.4
   Target Milestone|--- |4.7.4
Summary|ICE with trigraphs  |[4.7/4.8 Regression] ICE
   ||with trigraphs
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started ICEing in between r180075 and r180100.

[Bug preprocessor/60400] [4.7/4.8 Regression] ICE with trigraphs

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60400

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar  3 11:12:22 2014
New Revision: 208272

URL: http://gcc.gnu.org/viewcvs?rev=208272&root=gcc&view=rev
Log:
PR preprocessor/60400
* c-c++-common/cpp/pr60400.c: New test.
* c-c++-common/cpp/pr60400-1.h: New file.
* c-c++-common/cpp/pr60400-2.h: New file.

Added:
trunk/gcc/testsuite/c-c++-common/cpp/pr60400-1.h
trunk/gcc/testsuite/c-c++-common/cpp/pr60400-2.h
trunk/gcc/testsuite/c-c++-common/cpp/pr60400.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/60367] Default argument object is not getting constructed

[rob.desbois at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367

--- Comment #5 from rob.desbois at gmail dot com ---
The following is a side-by-side diff of the disassembly of the incorrect
version vs. a correct version (defaulting the parameter with = foo{}). The
object foo has a single member of type char initialized in default, move, and
copy ctors.

 incorrect version | correct version
---|---
push   %rbp   push   %rbp
mov%rsp,%rbp  mov%rsp,%rbp
push   %rbx   push   %rbx
sub$0x28,%rsp  |  sub$0x18,%rsp
lea-0x11(%rbp),%rax   lea-0x11(%rbp),%rax
mov%rax,%rdi  mov%rax,%rdi
callq  0x400bbe <_ZN3fooC2Ev>  |  callq  0x400bb8 <_ZN3fooC2Ev>
movzbl -0x11(%rbp),%eax|  lea-0x11(%rbp),%rax
mov%al,-0x30(%rbp) <   
lea-0x30(%rbp),%rax<   
mov%rax,%rdi  mov%rax,%rdi
callq  0x4009f0 <_Z6test_a3foo>|  callq  0x400a50 <_Z6test_b3foo>
lea-0x11(%rbp),%rax   lea-0x11(%rbp),%rax
mov%rax,%rdi  mov%rax,%rdi
callq  0x400bfe <_ZN3fooD2Ev>  |  callq  0x400bf8 <_ZN3fooD2Ev>
mov$0x0,%eax  mov$0x0,%eax
jmp0x400b65   |  jmp0x400b5e 
mov%rax,%rbx  mov%rax,%rbx
lea-0x11(%rbp),%rax   lea-0x11(%rbp),%rax
mov%rax,%rdi  mov%rax,%rdi
callq  0x400bfe <_ZN3fooD2Ev>  |  callq  0x400bf8 <_ZN3fooD2Ev>
mov%rbx,%rax  mov%rbx,%rax
mov%rax,%rdi  mov%rax,%rdi
callq  0x4008b0 <_Unwind_Resume@plt>  callq  0x4008b0
<_Unwind_Resume@plt>
add$0x28,%rsp  |  add$0x18,%rsp
pop%rbx   pop%rbx
pop%rbp   pop%rbp
retq  retq



It does look like the incorrect version on the left could be bitwise-copying
the default-constructed object.
As an aside - both versions have a single constructor call but TWO destructor
calls...

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
Bug 59859 depends on bug 58028, which changed state.

Bug 58028 Summary: [4.9 Regression] Several failures in libgomp.graphite after 
revision 200946
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028

   What|Removed |Added

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

[Bug tree-optimization/58028] [4.9 Regression] Several failures in libgomp.graphite after revision 200946

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Biener  ---
Fixed.

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Mon Mar  3 11:39:22 2014
New Revision: 208273

URL: http://gcc.gnu.org/viewcvs?rev=208273&root=gcc&view=rev
Log:
2014-03-03  Tobias Grosser  
Mircea Namolaru  

PR tree-optimization/58028
* graphite-clast-to-gimple.c (set_cloog_options): Don't remove
scalar dimensions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-clast-to-gimple.c

[Bug tree-optimization/54094] ICE in graphite-dependences.c:320 : isl_constraint.c:497: position out of bounds

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54094
Bug 54094 depends on bug 58028, which changed state.

Bug 58028 Summary: [4.9 Regression] Several failures in libgomp.graphite after 
revision 200946
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028

   What|Removed |Added

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

[Bug tree-optimization/58028] [4.9 Regression] Several failures in libgomp.graphite after revision 200946

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Biener  ---
Fixed.

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60370

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> This patch doesn't work, so it may not be a code ordering issue after all.

I think it *is* an ordering issue after all, and indeed your patch seems to fix
that in the sense that it makes sure that the bounds of 'b' are set before the
bounds-checking code is run.

However, it also seems to introduce another ordering issue: In particular the
bounds of 'b' are now set as

b.dim[1].lbound = 1;
b.dim[1].ubound = (D.2352 - D.2351) + 1;

before those temps are actually set via

  D.2351 = a.dim[0].lbound;
  D.2352 = a.dim[0].ubound;

[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 32252
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32252&action=edit
gcc49-pr58595.patch

Untested fix.  While the testcase does compile with -O2 -fpic -fno-gcse, I
don't see how it could work,
ldr r3, .L5
ldr r2, .L5+4
.LPIC0:
add r3, pc, r3
ldr r4, [r3, r2]
add r4, r4, #4
...
.L5:
.word   _GLOBAL_OFFSET_TABLE_-(.LPIC0+8)
.word   s(GOT)
simply can't load correct TLS symbol s value when s is in .tbss.

This untested patch does roughly what i386.c does, call legitimize_tls_address
even when we see a constant addition to a TLS SYMBOL_REF.

[Bug tree-optimization/60382] [4.8/4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu (in vect_create_epilog_for_reduction, at tree-vect-loop.c:4352)

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60382

--- Comment #3 from Richard Biener  ---
The issue is that in vectorizable_reduction we compute double_reduc in a wrong
way:

  if (nested_cycle)
{
  def_bb = gimple_bb (reduc_def_stmt);
  def_stmt_loop = def_bb->loop_father;
  def_arg = PHI_ARG_DEF_FROM_EDGE (reduc_def_stmt,
   loop_preheader_edge (def_stmt_loop));
  if (TREE_CODE (def_arg) == SSA_NAME
  && (def_arg_stmt = SSA_NAME_DEF_STMT (def_arg))
  && gimple_code (def_arg_stmt) == GIMPLE_PHI
  && flow_bb_inside_loop_p (outer_loop, gimple_bb (def_arg_stmt))
  && vinfo_for_stmt (def_arg_stmt)
  && STMT_VINFO_DEF_TYPE (vinfo_for_stmt (def_arg_stmt))
  == vect_double_reduction_def)
double_reduc = true;
}

that is because def_arg is a constant (and the outer loop reduction PHI
is dead).  Easiest is to not detect this as a valid reduction with
sth like

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 208269)
+++ gcc/tree-vect-loop.c(working copy)
@@ -2193,6 +2193,12 @@ vect_is_simple_reduction_1 (loop_vec_inf
   || (!check_reduction && flow_loop_nested_p (vect_loop, loop)));

   name = PHI_RESULT (phi);
+  /* ???  If there are no uses of the PHI result the inner loop reduction
+ won't be detected as possibly double-reduction by vectorizable_reduction
+ because that tries to walk the PHI arg from the preheader edge which
+ can be constant.  See PR60382.  */
+  if (has_zero_uses (name))
+return NULL;
   nloop_uses = 0;
   FOR_EACH_IMM_USE_FAST (use_p, imm_iter, name)
 {

[Bug middle-end/58479] [4.9 Regression] slow var-tracking on x86_64-linux at -O1 (and above) with -g, but checking disabled

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479

--- Comment #5 from Jakub Jelinek  ---
Alex, your thoughts on this?

[Bug fortran/59746] internal compiler error: Segmentation fault

[bdavis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59746

Bud Davis  changed:

   What|Removed |Added

 CC||bdavis at gcc dot gnu.org

--- Comment #2 from Bud Davis  ---
it looks like what was happening was the variable that was previously defined,
NVE, was not getting deleted out of the common block by
restore_last_undo_checkpoint.  Then the next time it was called, the common
block list was messed up.

The code would only remove a variable from a common block if it was just
defined in the previous statement.  I changed it so it would remove a variable
from a common block if it was just defined, or if it previously existed and was
put in the common block in the last statement.

This patch works with the example given and has no regressions in the
testsuite.

Short on time, wanted to save this info so it is not lost.  If anyone wants to
finish this up (testcase, blah. blah...) please feel free to do so.

--bud davis



[bdavis@budlinux1 current]$ svn diff gcc
Index: gcc/gcc/fortran/symbol.c
===
--- gcc/gcc/fortran/symbol.c(revision 208254)
+++ gcc/gcc/fortran/symbol.c(working copy)
@@ -3069,9 +3069,10 @@

   FOR_EACH_VEC_ELT (latest_undo_chgset->syms, i, p)
 {
-  if (p->gfc_new)
+  if (p->gfc_new || (p->old_symbol && !p->old_symbol->common_block))
 {
-  /* Symbol was new.  */
+  /* Symbol was new. Or it is old, and was just put in a common
+ block  */
   if (p->attr.in_common && p->common_block && p->common_block->head)
 {
   /* If the symbol was added to any common block, it
@@ -3092,7 +3093,9 @@
 }

   if (p->common_block->head == p)
+  {
 p->common_block->head = p->common_next;
+  }
   else
 {
   gfc_symbol *cparent, *csym;
@@ -3107,25 +3110,29 @@
 }

   gcc_assert(cparent->common_next == p);
-
   cparent->common_next = csym->common_next;
 }
 }
+}
+if (p->gfc_new)
+  {

-  /* The derived type is saved in the symtree with the first
- letter capitalized; the all lower-case version to the
- derived type contains its associated generic function.  */
-  if (p->attr.flavor == FL_DERIVED)
-gfc_delete_symtree (&p->ns->sym_root, gfc_get_string ("%c%s",
-(char) TOUPPER ((unsigned char) p->name[0]),
-&p->name[1]));
-  else
-gfc_delete_symtree (&p->ns->sym_root, p->name);
+/* The derived type is saved in the symtree with the first
+   letter capitalized; the all lower-case version to the
+   derived type contains its associated generic function.  */
+if (p->attr.flavor == FL_DERIVED)
+  gfc_delete_symtree (&p->ns->sym_root, gfc_get_string ("%c%s",
+  (char) TOUPPER ((unsigned char) p->name[0]),
+  &p->name[1]));
+else
+  gfc_delete_symtree (&p->ns->sym_root, p->name);

-  gfc_release_symbol (p);
-}
-  else
-restore_old_symbol (p);
+gfc_release_symbol (p);
+  }
+else
+  {
+restore_old_symbol (p);
+  }
 }

   latest_undo_chgset->syms.truncate (0);

[Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

Marek Polacek  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Seems like hppa only, thus does not merit P1.

[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE

[meadori at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595

--- Comment #5 from Meador Inge  ---
Created attachment 32253
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32253&action=edit
Work in progress patch.

Yeah, I am came to the same conclusion after making that comment that removing
the asserts is a bogus approach.

Although, my follow up approach is a little different.  I was trying to
replicate what we currently have in the 'movsi' pattern (see attached).  This
seems to work for the basic tests I have tried.  This patch is lightly tested,
is obviously in need of cleanup (since it duplicates code), and doesn't cover
the thumb case.  I am just posting it for discussion purposes.

Are we guaranteed to always have the const plus form?  Or do we need to be more
general like in the patch I attached?

-fopenmp fails when gcc is compiled to /usr/local

[John Frankish]

Using gcc-4.7.2 compiled to /usr/local

The following fails:

echo "int main(){}" > hello.c
gcc hello.c -fopenmp

..with a message that libgomp.spec cannot be found

editing the output of gcc -dumpspecs:

include(libgomp.spec) -> include(/usr/local/lib/libgomp.spec)
include(libitm.spec) -> include(/usr/local/lib/libitm.spec)

fixes the error, but shouldn't be required.

Regards
John

[Bug middle-end/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381

--- Comment #3 from Jakub Jelinek  ---
This seems to be due to r208220.

One problem I see is that when var-tracking.c calls cselib_preserve_only_values
+ cselib_reset_table, the latter clears n_useless_values (and
n_useless_debug_values) and drops non-preserved VALUEs with no locations, so
while we get rid of the non-preserved VALUEs with no locations, it can happen
that discard_useless_locs is never performed, even when the cumulative number
of dropped useless locs became very large.

So, I wonder if r208220 shouldn't be reverted and instead we'd use slightly
different condition on when to call remove_useless_values from
cselib_preserve_only_values, or perhaps just do the
  do
{
  values_became_useless = 0;
  cselib_hash_table.traverse  (NULL);
}
  while (values_became_useless);
part of remove_useless_values, since the rest of the function does nothing or
is useless with the immediately following cselib_reset_table (is it?) or
cselib_invalidate_mem (callmem) done right before that.  For the different
condition, I'd imagine that for cselib_preserve_constants we'd sum up in some
new int variable the n_useless_values counts from entry to cselib_reset_table,
and clear that inside of remove_useless_locs and use that in the guard
condition when to discard useless locs from cselib_preserve_only_values.  Thus,
if we say have 3 ebbs and in each of them gain say 10 useless values (that
are dropped), we'd eventually discard_useless_locs at least after some ebbs,
though not after each one.

Also, I wonder because of this ICE if we shouldn't forcefully
remove_useless_values (if any values have become useless since last
discard_useless_locs call) at the end of vt_initialize, to make sure we don't
have useless locs at the end, and also
cselib_preserved_hash_table.traverse  (NULL);
after that (so that we don't reference non-preserved VALUEs from preserved
VALUE locs).  We don't need to retry that, because cselib_preserved_hash_table
contains only preserved values and thus value_became_useless should be always
unchanged while walking that table.

[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Kyrill (or anyone else), do you think you could bootstrap/regtest that (sorry
for that, but my access to ARM hw is limited)?

[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595

--- Comment #7 from Jakub Jelinek  ---
(In reply to Meador Inge from comment #5)
> Created attachment 32253 [details]
> Work in progress patch.
> 
> Yeah, I am came to the same conclusion after making that comment that
> removing the asserts is a bogus approach.
> 
> Although, my follow up approach is a little different.  I was trying to
> replicate what we currently have in the 'movsi' pattern (see attached). 
> This seems to work for the basic tests I have tried.  This patch is lightly
> tested, is obviously in need of cleanup (since it duplicates code), and
> doesn't cover the thumb case.  I am just posting it for discussion purposes.
> 
> Are we guaranteed to always have the const plus form?  Or do we need to be
> more general like in the patch I attached?

It is good enough for i?86/x86_64, so I don't see why it wouldn't be for arm.
Note, this is about what the middle-end is prepared to feed to emit_move_insn,
I can't imagine it would feed something more complex than that.

rs6000 has code similar to your case and has the assert in there too.

Another alternative would be to have something like your patch, but do the
check before the
if (!TARGET_ARM)
case in arm_legitimize_address and drop the TLS handling in
thumb_legitimize_address to avoid the duplication.  I wonder how it can work on
thumb2 anyway without legitimizing TLS.
BTW, the force_operand is perhaps unnecessary, but perhaps we should recurse
into arm_legitimize_address instead, so that it takes care of out of range
addends?

[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595

--- Comment #8 from Jakub Jelinek  ---
Created attachment 32254
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32254&action=edit
gcc49-pr58595-2.patch

So what about this variant?

[Bug libstdc++/60401] New: stdlib.h does not provide abs(long) overload

[sbergman at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60401

Bug ID: 60401
   Summary: stdlib.h does not provide abs(long) overload
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com

When libstdc++ sits on top of glibc, including stdlib.h does not provide an
abs(long) overload (unlike including cstdlib providing a std::abs(long)
overload).

Similarly for C++11 abs(long long) and stdlib.h vs. cmath abs(float/double/long
double).

(Fixing this needs cooperation with glibc, see the mail thread starting at
 "stdlib.h abs(long)
overload?")

[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595

--- Comment #9 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 32254 [details]
> gcc49-pr58595-2.patch
> 
> So what about this variant?

I'll give this a bootstrap and test run, thanks

[Bug c++/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.

[m_nistor at yahoo dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387

--- Comment #2 from Nistor, Mihail-Marian  ---
More details about how to reproduce the first problem. 
By using the gcc version - GNU C 4.8.1 20130531 (Wed Sep 4 08:04:01 CDT 2013)
I have defined a local variable (vf1) that has a vector resister as storage
class, the C definition is below:
register vector float vf1 = {0.1f, 0.2f, 0.3f, 0.4f};
A piece of dump from .debug_info is below: 
<2><24f>: Abbrev Number: 7 (DW_TAG_variable)
<250>   DW_AT_name: vf1
<254>   DW_AT_decl_file   : 1
<255>   DW_AT_decl_line   : 13
<256>   DW_AT_type: <0x2ee>
<25a>   DW_AT_location: 2 byte block: 90 64 (DW_OP_regx: 100
(r100)) // the correct expression should be: (DW_OP_regx: 1124 (r1124))
A piece of dump from .debug_frame is below:
00d0 0034 00c0 FDE cie=00c0 pc=0010018c..001002fc
  DW_CFA_advance_loc: 4 to 00100190
  DW_CFA_def_cfa_offset: 192
  DW_CFA_advance_loc: 84 to 001001e4
  DW_CFA_offset_extended_sf: r65 at cfa+4
  DW_CFA_offset: r31 at cfa-4
  DW_CFA_offset_extended: r100 at cfa-160 // the correct expression should be:
r1124 at cfa-160

As you can see, the compiler uses a wrong DWARF register index for vector
register, in this case the compiler should generate  1124 (r1124) instead of
100 (r100), so the ppc gcc compiler is not compatible with the PPC ABI. 

Please let me know if you need more information to reproduce the second
problem.

[Bug c++/60399] constexpr ctor that does not init an attribute should be rejected but isn't

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60399

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  ---
No, the compiler is conforming: According to 7.1.6 p6:

"If the instantiated template specialization of a constexpr [..] member
function of a class template would fail to satisfy the requirements for a
constexpr function or constexpr constructor, that specialization is still a
constexpr function or constexpr constructor, even though a call to such a
function
cannot appear in a constant expression."

So, per se, the situation is well-defined here and there is fundamentally
nothing wrong with the constructor, because your code does not attempt to use
it in a constant expression. 

What makes your code ill-formed is the fact that your template could never be
instantiated to make the constructor a constexpr constructor, see the following
sentence:

"If no specialization of the template would satisfy the requirements for
a constexpr function or constexpr constructor when considered as a non-template
function or constructor, the template is ill-formed; no diagnostic required."

As you may notice, this kind of code does not require a diagnostics.

[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified

[fredrik at lysator dot liu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638

Fredrik Nyström  changed:

   What|Removed |Added

 CC||fredrik at lysator dot liu.se

--- Comment #3 from Fredrik Nyström  ---
Seems to be a bug in libstdc++-v3/configure, same in both gcc-4.8 and gcc-4.9.

Suggested fix:

--- libstdc++-v3/configure~ 2013-11-22 14:17:55.0 +0100
+++ libstdc++-v3/configure  2014-03-03 20:01:32.0 +0100
@@ -14909,25 +14909,25 @@
 # libtool variables for C++ shared and position-independent compiles.
 #
 # Use glibcxx_lt_pic_flag to designate the automake variable
 # used to encapsulate the default libtool approach to creating objects
 # with position-independent code. Default: -prefer-pic.
 #
 # Use glibcxx_compiler_shared_flag to designate a compile-time flags for
 # creating shared objects. Default: -D_GLIBCXX_SHARED.
 #
 # Use glibcxx_compiler_pic_flag to designate a compile-time flags for
 # creating position-independent objects. This varies with the target
 # hardware and operating system, but is often: -DPIC -fPIC.
-if test "$enable_shared" = yes; then
+if test "$enable_shared" = yes || test "${with_pic+set}" = set; then
   glibcxx_lt_pic_flag="-prefer-pic"
   glibcxx_compiler_pic_flag="$lt_prog_compiler_pic_CXX"
   glibcxx_compiler_shared_flag="-D_GLIBCXX_SHARED"

 else
   glibcxx_lt_pic_flag=
   glibcxx_compiler_pic_flag=
   glibcxx_compiler_shared_flag=
 fi

[Bug c++/60402] New: const overload with variadics declared ambiguous according to standard (may be related to bug 58156)

[nate.mcnamara at morganstanley dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60402

Bug ID: 60402
   Summary: const overload with variadics declared ambiguous
according to standard (may be related to bug 58156)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nate.mcnamara at morganstanley dot com

Created attachment 32255
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32255&action=edit
preprocessed source

$ g++ -v
Reading specs from
/ms/dist/fsf/PROJ/gcc/4.8.1/.exec/@sys/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/specs
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/ms/dist/fsf/PROJ/gcc/4.8.1/.exec/@sys/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: //ms/dev/fsf/gcc/4.8.1/src/gcc-4.8.1/configure
--prefix=//ms/dist/fsf/PROJ/gcc/4.8.1/.exec/x86_64.linux.2.6.glibc.2.3
--exec-prefix=//ms/dist/fsf/PROJ/gcc/4.8.1/.exec/x86_64.linux.2.6.glibc.2.3
--disable-checking --enable-threads=posix --enable-__cxa_atexit
--enable-languages=c,c++,fortran
--with-gmp=//ms/dev/fsf/gcc/4.8.1/install/.exec/x86_64.linux.2.6.glibc.2.3
--with-mpfr=//ms/dev/fsf/gcc/4.8.1/install/.exec/x86_64.linux.2.6.glibc.2.3
--with-mpc=//ms/dev/fsf/gcc/4.8.1/install/.exec/x86_64.linux.2.6.glibc.2.3
--enable-linker-build-id
--with-cloog=//ms/dev/fsf/gcc/4.8.1/install/.exec/x86_64.linux.2.6.glibc.2.3
--with-isl=//ms/dev/fsf/gcc/4.8.1/install/.exec/x86_64.linux.2.6.glibc.2.3
--with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.8.1 (GCC)
$ g++ -std=c++11 ambiguous.cpp
ambiguous.cpp: In instantiation of 'void f(const char*, T ...) [with T =
{int}]':
ambiguous.cpp:12:14:   required from here
ambiguous.cpp:7:51: warning: ISO C++ says that these are ambiguous, even though
the worst conversion for the first is better than the worst conversion for the
second: [enabled by default]
   f(const_cast(s), std::forward(args)...);
   ^
ambiguous.cpp:6:6: note: candidate 1: void f(const char*, T ...) [with T =
{int}]
 void f(const char* s, T... args) {
  ^
ambiguous.cpp:3:6: note: candidate 2: void f(char*, ...)
 void f(char* s, ...) {}
  ^

[Bug c++/60402] const overload with variadics declared ambiguous according to standard (may be related to bug 58156)

[nate.mcnamara at morganstanley dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60402

--- Comment #1 from Nate McNamara  ---
Created attachment 32256
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32256&action=edit
preprocessed source

[Bug c++/60402] const overload with variadics declared ambiguous according to standard (may be related to bug 58156)

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60402

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #2 from Daniel Krügler  ---
No, this is not related to bug 58156. According to the current core language of
C++11, the code is indeed ambiguous.

There exists currently a core language issue to fix that, see

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1395

[Bug c++/60361] [4.7/4.8/4.9 Regression] unexpected 'use of parameter outside function body' error

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/60361] [4.7/4.8/4.9 Regression] unexpected 'use of parameter outside function body' error

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361

Jason Merrill  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |4.7.4

[Bug fortran/60370] TRANSPOSE on rhs of allocatable array assignment gives error with -fcheck=bounds

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60370

--- Comment #6 from Mikael Morin  ---
(In reply to janus from comment #5)
> However, it also seems to introduce another ordering issue: In particular
> the bounds of 'b' are now set as
> 
> b.dim[1].lbound = 1;
> b.dim[1].ubound = (D.2352 - D.2351) + 1;
> 
> before those temps are actually set via
> 
>   D.2351 = a.dim[0].lbound;
>   D.2352 = a.dim[0].ubound;

Hmm, no those are correctly ordered, but I see what you mean; and it's actually
diagnosed by the compiler when warnings and optimizations are enabled:
Namely this happens:

  D.2339 = b.dim[1].lbound;
  D.2340 = b.dim[1].ubound;

before b has been initialized.

So the reallocation code has to also happen before b's bounds are evaluated.
Even more tricky... :-(

[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[OOP] ICE on valid with |[4.9 Regression] [OOP] ICE
   |FINAL function and type |on valid with FINAL
   |extension   |function and type extension

--- Comment #2 from janus at gcc dot gnu.org ---
I guess it's fair to say that the ICE is technically a regression.

[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880

--- Comment #3 from Dominique d'Humieres  ---
> I guess it's fair to say that the ICE is technically a regression.

The test in comment 0 compiles with r199394 to r199408. The Ice starts at
r199409.
So it is a real regression within 4.9.0.

[Bug libitm/57643] libitm.c/reentrant.c hangs on POWER8 with HTM

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643

--- Comment #2 from Peter Bergner  ---
Author: bergner
Date: Mon Mar  3 22:13:28 2014
New Revision: 208295

URL: http://gcc.gnu.org/viewcvs?rev=208295&root=gcc&view=rev
Log:
Backport from mainline
2013-06-20  Torvald Riegel  

* query.cc (_ITM_inTransaction): Abort when using the HTM fastpath.
(_ITM_getTransactionId): Same.
* config/x86/target.h (htm_transaction_active): New.

2013-06-20  Torvald Riegel  

PR libitm/57643
* beginend.cc (gtm_thread::begin_transaction): Handle reentrancy in
the HTM fastpath.

Modified:
branches/gcc-4_8-branch/libitm/ChangeLog
branches/gcc-4_8-branch/libitm/beginend.cc
branches/gcc-4_8-branch/libitm/config/x86/target.h
branches/gcc-4_8-branch/libitm/query.cc

[Bug libfortran/48587] Avoid exhausting unit number with NEWUNIT=

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48587

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #7 from Janne Blomqvist  ---
I have a preliminary patch, which I'm planning to finish and submit when 4.10
stage 1 opens. Assigning to myself.

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

[mizvekov at gmail dot com]

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

Matheus Izvekov  changed:

   What|Removed |Added

 CC||mizvekov at gmail dot com

--- Comment #9 from Matheus Izvekov  ---
Still an issue on GCC 4.8.2

[Bug ada/60403] New: fatal error, system.ads not formatted correctly

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60403

Bug ID: 60403
   Summary: fatal error, system.ads not formatted correctly
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa1.1-hp-hpux10.20
Target: hppa1.1-hp-hpux10.20
 Build: hppa1.1-hp-hpux10.20

/xxx/gnu/gcc/objdir/./prev-gcc/xgcc -B/xxx/gnu/gcc/objdir/./prev-gcc/
-B/opt/gnu/gcc/gcc-4.9/hppa1.1-hp-hpux10.20/bin/
-B/opt/gnu/gcc/gcc-4.9/hppa1.1-hp-hpux10.20/bin/
-B/opt/gnu/gcc/gcc-4.9/hppa1.1-hp-hpux10.20/lib/ -isystem
/opt/gnu/gcc/gcc-4.9/hppa1.1-hp-hpux10.20/include -isystem
/opt/gnu/gcc/gcc-4.9/hppa1.1-hp-hpux10.20/sys-include-c -g -O2
-mdisable-indexing -D_X_HPUX10 -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada
-I../../gcc/gcc/ada -I../../gcc/gcc/ada/gcc-interface
../../gcc/gcc/ada/a-charac.ads -o ada/a-charac.o
fatal error, system.ads not formatted correctly
unexpected end of file
compilation abandoned
make[3]: *** [ada/a-charac.o] Error 1

Occurs in stage2.

Seen in revision 208212.

[Bug rtl-optimization/60155] ICE: in get_pressure_class_and_nregs at gcse.c:3438

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60155

--- Comment #10 from John David Anglin  ---
Bah, doesn't fix bug:

dave@mx3210:~/gnu/gcc/objdir$ gcc/xgcc -Bgcc/ -g -O2 -Wall -Wpointer-arith
-Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess
-Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2
-ftrapv -fno-builtin-memset -D_FORTIFY_SOURCE=2 -g -O2 -Wformat
-Werror=format-security -fpreprocessed ../ssh-keygen.i
../ssh-keygen.c: In function ‘do_fingerprint’:
../ssh-keygen.c:887:1: internal compiler error: in hoist_code, at gcse.c:3378
0x5bf083 hoist_code
../../gcc/gcc/gcse.c:3378
0x5c00bf one_code_hoisting_pass
../../gcc/gcc/gcse.c:3651
0x5c15f3 execute_rtl_hoist
../../gcc/gcc/gcse.c:4171
0x5c17ef execute
../../gcc/gcc/gcse.c:4244

[Bug c++/60387] The gcc compiler for the ppc architecture is not compatible with PPC ABI and DWARF standards.

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60387

--- Comment #3 from Andrew Pinski  ---
(In reply to Nistor, Mihail-Marian from comment #2)
> Please let me know if you need more information to reproduce the second
> problem.

Yes please provide the preprocesed source and the exact options you used to
compiled it.  Also provide the exact options (and version) you used to
configure GCC (you can get that via gcc -v).

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148

--- Comment #11 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Mar  4 04:33:40 2014
New Revision: 208302

URL: http://gcc.gnu.org/viewcvs?rev=208302&root=gcc&view=rev
Log:
2014-03-03  Jerry DeLisle  

PR libfortran/60148
* io/inquire.c (inquire_via_unit): In the case of
DELIM_UNSPECIFIED set inquire return string to "NONE".
* io/list_read.c (read_character): In the case of DELIM_NONE and
namelists, complete the character read using the namelist
variable length.
* io/open.c (new_unit): Don't set delim status to none if not
specified so that DELIM_UNSPECIFIED can be used later.
* io/transfer.c (data_transfer_init): For namelist I/O, if the
unit delim status is unspecified set the current status to quote.
Otherwise, set current status to the unit status.
* io/unit.c (get_internel_unit, init_unit): Remember to set
flags_delim initially to DELIM_UNSPECIFIED so defaults come out
correctly.
* io/write.c (write_character): Add a new function argument
"mode" to signify that raw output is to be used vs output with
delimiters. If the mode is set to DELIM (1) proceed with
delimiters. (list_formatted_write_scalar): Write the separator
only if a delimiter was previously specified. Update the call to
write_character with the mode argument given.
(namelist_write_newline): Use the mode argument. (nml_write_obj):
Use the mode argument. Remove use of tmp_delim. Write the
semi-colon or comma correctly only when needed with using
delimiters. Cleanup whitespace.
(namelist_write): If delim is not specified in namelist I/O,
defaultto using quotes. Get rid of the tmp_delim variable and
use the new mode argument in write_character.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/inquire.c
trunk/libgfortran/io/list_read.c
trunk/libgfortran/io/open.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unit.c
trunk/libgfortran/io/write.c

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60148

--- Comment #12 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Mar  4 05:46:06 2014
New Revision: 208303

URL: http://gcc.gnu.org/viewcvs?rev=208303&root=gcc&view=rev
Log:
2014-03-03  Jerry DeLisle  

PR libfortran/60148
* gfortran.dg/namelist_84.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_84.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug lto/60404] New: wrong code by LTO on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60404

Bug ID: 60404
   Summary: wrong code by LTO on x86_64-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk miscompiles the following code when using LTO on
x86_64-linux-gnu in both 32-bit and 64-bit modes. 

This is a regression from 4.8.x. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140303 (experimental) [trunk revision 208268] (GCC) 
$ 
$ gcc-trunk -flto -O1 -c fn1.c
$ gcc-trunk -flto -O1 -c fn2.c
$ gcc-trunk -flto -O1 -c main.c
$ gcc-trunk -flto -O0 fn1.o fn2.o main.o   
$ a.out
1
$ 
$ gcc-4.8.2 -flto -O1 -c fn1.c
$ gcc-4.8.2 -flto -O1 -c fn2.c
$ gcc-4.8.2 -flto -O1 -c main.c
$ gcc-4.8.2 -flto -O0 fn1.o fn2.o main.o
$ a.out
0
$ 
$ gcc-trunk -O0 fn1.c fn2.c main.c
$ a.out
0
$ 
$ cat fn1.c 
void
fn1 (int p)
{
}
$ cat fn2.c
extern int b;

extern void fn1 (int);

void
fn2 (int p)
{
  b = p++;
  fn1 (p);
}
$ cat main.c
int printf (const char *, ...);

extern void fn2 (int);

int a[1];
int b;

int
main ()
{
  fn2 (0);
  printf ("%d\n", a[b]);
  return 0;
}
$

[Bug lto/60405] New: ICE in lto1 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60405

Bug ID: 60405
   Summary: ICE in lto1 on x86_64-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk produces an ICE in lto1 when attempting to link an object
file generated by 4.8.2. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140303 (experimental) [trunk revision 208268] (GCC) 
$   
$ gcc-4.8.2 -flto -O0 -c foo.c
$ 
$ gcc-trunk -flto -O0 foo.o
lto1: internal compiler error: Segmentation fault
0x89919f crash_signal
../../gcc-trunk/gcc/toplev.c:337
0xa57442 streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*)
../../gcc-trunk/gcc/tree-streamer-in.c:547
0x79fe21 lto_read_tree_1
../../gcc-trunk/gcc/lto-streamer-in.c:1136
0x7a035c lto_read_tree
../../gcc-trunk/gcc/lto-streamer-in.c:1173
0x7a035c lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../gcc-trunk/gcc/lto-streamer-in.c:1294
0x4f9ac1 lto_read_decls
../../gcc-trunk/gcc/lto/lto.c:1961
0x4fbb83 lto_file_finalize
../../gcc-trunk/gcc/lto/lto.c:2214
0x4fbb83 lto_create_files_from_ids
../../gcc-trunk/gcc/lto/lto.c:2224
0x4fbb83 lto_file_read
../../gcc-trunk/gcc/lto/lto.c:2264
0x4fbb83 read_cgraph_and_symbols
../../gcc-trunk/gcc/lto/lto.c:2969
0x4fbb83 lto_main()
../../gcc-trunk/gcc/lto/lto.c:3406
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.
lto-wrapper: gcc-trunk returned 1 exit status
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ 
$ 
$ cat foo.c
int 
main () 
{
  return 0;
}

[Bug go/60406] New: reflect.go:test13reflect2 test failure

[vogt at linux dot vnet.ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406

Bug ID: 60406
   Summary: reflect.go:test13reflect2 test failure
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: vogt at linux dot vnet.ibm.com

>From a email discussion between me (DV) and Ian Lance Taylor (IT):

DV: The bug shows up when running recover.go from the go testsuite
DV: in the function test13reflect2 (and test14reflect2).
DV:
DV: When panic is called, the deferred reflection function is invoked
DV: by calling the thunk function.  (See below for the assembly code
DV: on s390).  The call to __go_set_defer_retaddr is passed the address
DV: of a label that was generated originally right behind the call to
DV: makeFuncStub, and the fake jump is there to make sure the
DV: automatically generated label does not get deleted during
DV: compilation.  However, in the assembler code a different address
DV: is passed to __go_set_defer_retaddr that the target address of the
DV: fake jump:
DV:
DV: -- snip assembler code --
DV:   80002490 :
DV: ...
DV: 8000249e:  larl  %r2,800024f4  ---
DV: 800024a4:  brasl %r14,80002c48 <__go_set_defer_retaddr>  |
DV: 800024aa:  tmll  %r2,255 |
DV: # fake jump  |
DV: 800024ae:  jne   80002500     |
DV: 800024b2:  ltgr  %r13,%r13|  |
DV: ...   |  |
DV: # code that copies T5 |  |
DV: 800024de:  lghi  %r3,31   |  |
DV: 800024e2:  mvc   0(256,%r2),0(%r1)|  |
DV: 800024e8:  la%r2,256(%r2) |  |
DV: 800024ec:  la%r1,256(%r1) |  |
DV: 800024f0:  brctg %r3,800024e2  |  |
DV: # wrong position of split label   |  |
DV: 800024f4:  mvc   0(256,%r2),0(%r1)<---|--
DV: 800024fa:  la%r2,160(%r15)|
DV: # call makeFuncStub   |
DV: 800024fe:  basr  %r14,%r13  <--- makeFuncStub |
DV: # original position of the label "retaddr"|
DV: 80002500:  lghi  %r2,0<---
DV: ...
DV: -- snip --
DV:
DV: The code in libgo/runtime/go-recover.c:__go_can_recover tests
DV: whether the address passed to __go_set_defer_retaddr is in a
DV: certain range around the the real return address of makeFuncStub:
DV:
DV:   if (ret <= dret && ret + 16 >= dret)
DV: return 1;
DV:
DV: In the above assembly language code the assumption that the defer
DV: retaddr will always end up in that range is violated.  Thus,
DV: __go_can_recover returns 0, the panic is not recovered and the test
DV: case fails.
DV:
DV: --
DV:
DV: There are two problems in the current code.  First, the assumption
DV: in __go_can_recover is too strict.  I think the "correct" test
DV: would be to check whether dret is inside the thunk function, i.e.
DV:
DV:   if (dret >= thunk_start && dret < thunk_end)
DV: return 1;

IT: Yes.


DV: Except that thunk_start and thunk_end are not easily available at
DV: that place.


IT: Well, we could get thunk_start fairly easily: we could pass it to
IT: __go_set_defer_retaddr, just as we currently pass the return label.  I
IT: can't think of a reliable way for us to get thunk_end, though.


DV: Second, the code ("hack") in gcc/go/gofrontend/statementis.cc:build_thunk()
DV: simply does not work:
DV:
DV: -- snip --
DV:   // For a defer statement, start with a call to
DV:   // __go_set_defer_retaddr.  */
DV:   Label* retaddr_label = NULL;
DV:   if (may_call_recover)
DV: {
DV:   retaddr_label = gogo->add_label_reference("retaddr", location,
false);
DV:   Expression* arg = Expression::make_label_addr(retaddr_label,
location);
DV:   Expression* call = Runtime::make_call(Runtime::SET_DEFER_RETADDR,
DV: location, 1, arg);
DV:
DV:   // This is a hack to prevent the middle-end from deleting the
DV:   // label.
DV:   gogo->start_block(location);
DV:   gogo->add_statement(Statement::make_goto_statement(retaddr_label,
DV:  location));
DV:   ...
DV: }
DV:
DV:   ...
DV:
DV:   // If this is a defer statement, the label comes immediately after
DV:   // the call.
DV:   if (may_call_recover)
DV: {
DV:   gogo->add_label_definition("retaddr", location);
DV:   ...
DV: }
DV: -- snip --
DV:
DV: The address of the label "retaddr" is passed to
DV: __go_set_defer_retaddr and then a fake jump to that label is
DV: inserted after that (fake because __go_set_defer_retaddr always
DV: returns 0).  Although the fake jump does prevent