[Bug target/60264] ARM ICE in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1090

[zqchen at gcc dot gnu.org]

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

--- Comment #3 from zqchen at gcc dot gnu.org ---
Author: zqchen
Date: Wed Apr  2 06:45:59 2014
New Revision: 209009

URL: http://gcc.gnu.org/viewcvs?rev=209009&root=gcc&view=rev
Log:
gcc/
2014-04-02  Zhenqiang Chen  

Backport from trunk r208511
2014-03-12  Christian Bruel  

PR target/60264
* config/arm/arm.c (arm_emit_vfp_multi_reg_pop): Emit a
REG_CFA_DEF_CFA note.
(arm_expand_epilogue_apcs_frame): call arm_add_cfa_adjust_cfa_note.
(arm_unwind_emit): Allow REG_CFA_DEF_CFA.

gcc/testsuite/
2014-04-02  Zhenqiang Chen  

Backport from trunk r208511
2014-03-12  Christian Bruel  

PR target/60264
* gcc.target/arm/pr60264.c


Added:
branches/linaro/gcc-4_8-branch/gcc/testsuite/gcc.target/arm/pr60264.c
Modified:
branches/linaro/gcc-4_8-branch/gcc/ChangeLog.linaro
branches/linaro/gcc-4_8-branch/gcc/config/arm/arm.c
branches/linaro/gcc-4_8-branch/gcc/testsuite/ChangeLog.linaro

[Bug c++/57887] nested non-type template parameters not declared in this scope

[jaak at ristioja dot ee]

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

Jaak Ristioja  changed:

   What|Removed |Added

 CC||jaak at ristioja dot ee

--- Comment #8 from Jaak Ristioja  ---
As a result of a discussion on IRC (#gcc @ OTFC) we came to the conclusion that
GCC parsing of the following code (compare with code in Comment #0) was also
probably fixed by 204818.

struct Outer {
  template 
  struct Inner {
enum Type { TYPE_1 };
Type m_type = TYPE_1;
  };
};

Resulted in ICE in GCC 4.7.3 and "invalid use of incomplete type 'enum
Outer::Inner<  >::Type'" in GCC 4.8.2. It was confirmed
by user jwakely to parse with GCC 4.9.

[Bug rtl-optimization/60738] New: A missing opportunity about process_single_reg_class_operands

[wmi at google dot com]

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

Bug ID: 60738
   Summary: A missing opportunity about
process_single_reg_class_operands
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wmi at google dot com

Testcase 1.c:

int a, b, c, d, e, cond;
void foo() {
  int r1, r2, r3;
  r1 = b;
  r2 = d;
  if (__builtin_expect(cond > 3, 0)) {
e = e * 5;
c = a << r1;
  }
  c = c << r2;
  __builtin_printf("r1 + r2 = %d\n", r1 + r2);
}

~/workarea/gcc-r208410/build/install/bin/gcc -O2 -S 1.c

foo:
.LFB0:
.cfi_startproc
cmpl$3, cond(%rip)
movlb(%rip), %esi
movld(%rip), %eax
jg  .L2
movlc(%rip), %edx
.L3:
movl%eax, %ecx  // r2 gets assigned %eax. This is reload for
insn1.
addl%eax, %esi
movl$.LC0, %edi
sall%cl, %edx   // insn1. Its constraint requires r2 in %ecx
xorl%eax, %eax
movl%edx, c(%rip)
jmp printf
.p2align 4,,10
.p2align 3
.L2:
movle(%rip), %edx
movl%esi, %ecx  // r1 gets assigned %esi. This is reload for
insn2.
leal(%rdx,%rdx,4), %edx
movl%edx, e(%rip)
movla(%rip), %edx
sall%cl, %edx   // insn2. Its constraint requires r1 in %ecx
jmp .L3
.cfi_endproc

Because the bb starting from L2 is relatively cold, it is better to generate
the code below:

foo:
.LFB0:
.cfi_startproc
cmpl$3, cond(%rip)
movlb(%rip), %esi
movld(%rip), %ecx
jg  .L2
movlc(%rip), %eax
.L3:
sall%cl, %eax   // r2 gets assigned %ecx. no reload is
needed.
addl%ecx, %esi
movl$.LC0, %edi
movl%eax, c(%rip)
xorl%eax, %eax
jmp printf
.p2align 4,,10
.p2align 3
.L2:
movle(%rip), %eax
movl%ecx, %edx   // r2's live range is splitted here. This
is the start of the splitted live range.
movl%esi, %ecx   // r1 gets assigned %esi, this is reload
for insn2. 
leal(%rax,%rax,4), %eax
movl%eax, e(%rip)
movla(%rip), %eax
sall%cl, %eax// insn2. constraint of insn2 requires r1
in %ecx
movl%edx, %ecx   // r2's live range is splitted here. This
is the end of the splitted live range.
jmp .L3
.cfi_endproc

Now there is less code in the hotpath (The bb starting from .L3).

r1 and r2 used in sall insns need CX_REG class which is
single_reg_operand_class in IRA. Existing logic in
process_single_reg_class_operands in ira-lives.c doesn't allow %ecx to being
assigned to r1 or r2. May it need improvement here?

[Bug middle-end/60737] rs6000 expand_block_clear uses word stores on double word pointer

[anton at samba dot org]

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

--- Comment #1 from Anton Blanchard  ---
It looks like by the time we get to expand_block_clear we don't have any
alignment info (align_rtx == 1).

[Bug middle-end/60737] New: rs6000 expand_block_clear uses word stores on double word pointer

[anton at samba dot org]

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

Bug ID: 60737
   Summary: rs6000 expand_block_clear uses word stores on double
word pointer
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org

The following code:

#include 

void foo(long *p)
{   
memset(p, 0, 16);
}

When built with a 64bit target:

gcc -mcpu=power8 -O2 -S foo.c

Ends up using 32 byte stores:

foo:
li 9,0
stw 9,0(3)
stw 9,4(3)
stw 9,8(3)
stw 9,12(3)
blr

expand_block_move has a similar issue

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #1 from mrs at gcc dot gnu.org  ---
The flag is documented to default to 2.  Darwin does nothing special here (that
I could find or remember).  One simply cannot change mangling without checking
this flag.  If the flag doesn't change, then how can the mangling change?

If one wants to check a new mangling, then they have to use -fabi-version=n,
where is the the version they want to check.  I don't see why that would be
dependent upon darwin; it should be unconditional.

Confused.

[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems

[ppluzhnikov at google dot com]

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

Paul Pluzhnikov  changed:

   What|Removed |Added

 CC||ppluzhnikov at google dot com

--- Comment #1 from Paul Pluzhnikov  ---
Google ref: b/13731165

This appears to be a 4.9 regression.

[Bug preprocessor/60736] New: Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems

[ian at airs dot com]

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

Bug ID: 60736
   Summary: Crash in preprocessor including stdc-predef.h when it
does not exist on glibc-based systems
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com

The file stdc-predef.h is special on glibc-based systems, as GCC pretends that
it does a #include of that file first.  My system (Ubuntu Precise) does not
have stdc-predef.h.  That case is supposed to work.  However, if the program
attempts to #include , which should fail, the compiler crashes
rather than reporting an error.

In other words, on a system without , this crashes:

echo "#include " | gcc -x c -

:1:0: internal compiler error: Segmentation fault
0x9ad9cf crash_signal
../../gccgo3/gcc/toplev.c:336
0xf35ba6 cpp_errno(cpp_reader*, int, char const*)
../../gccgo3/libcpp/errors.c:233
0xf3af13 _cpp_find_file
../../gccgo3/libcpp/files.c:571
0xf3b621 _cpp_stack_include
../../gccgo3/libcpp/files.c:993
0xf32b20 do_include_common
../../gccgo3/libcpp/directives.c:793
0xf336c0 _cpp_handle_directive
../../gccgo3/libcpp/directives.c:492
0xf40ad4 _cpp_lex_token
../../gccgo3/libcpp/lex.c:2067
0xf45887 cpp_get_token_1
../../gccgo3/libcpp/macro.c:2362
0x5ee37a c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gccgo3/gcc/c-family/c-lex.c:302
0x584a93 c_lex_one_token
../../gccgo3/gcc/c/c-parser.c:228
0x5a389d c_parser_peek_token
../../gccgo3/gcc/c/c-parser.c:408
0x5a389d c_parse_file()
../../gccgo3/gcc/c/c-parser.c:13809
0x5f6894 c_common_parse_file()
../../gccgo3/gcc/c-family/c-opts.c:1056
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/60735] GCC targeting E500 with SPE has errors with the _Decimal64 type

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 32520
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32520&action=edit
Proposed patch to fix the problem

The issue is there was no insn to support movdd if -mspe.  I fixed the code to
provide the insn for 32-bit moves.  In looking at the code, there were some
thinkos in that the moves for DFmode and DDmode where testing
TARGET_SINGLE_FLOAT and TARGET_E500_SINGLE, when these types are double.  In
addition, I disabled the FPRs being considered available if software floating
point or floating point is not done in FPRS (i.e. spe).

[Bug target/60735] GCC targeting E500 with SPE has errors with the _Decimal64 type

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Target||powerpc-linuxspe
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-04-01
 CC||bergner at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||pthaugen at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/60735] New: GCC targeting E500 with SPE has errors with the _Decimal64 type

[meissner at gcc dot gnu.org]

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

Bug ID: 60735
   Summary: GCC targeting E500 with SPE has errors with the
_Decimal64 type
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org

Created attachment 32519
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32519&action=edit
Example program, fails with -O3 on a powerpc-linuxspe target.

In my October 17th, 2013 changes to clean up the powerpc addressing issues, I
broke the use of DDmode (_Decimal64) on SPE systems.  This shows up in building
libgcc.  The issue is none of the moves of DDmode worked in the case where the
system had SPE double floating point, which puts double precision values in
GPRs.  However, the DDmode is not handled in the same fashion, and it fell
through the cracks.

[Bug c++/59361] cannot expand parenthesized pack expression

[eric.niebler at gmail dot com]

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

--- Comment #1 from Eric Niebler  ---
Anybody?

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

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Apr  1 21:25:20 2014
New Revision: 208999

URL: http://gcc.gnu.org/viewcvs?rev=208999&root=gcc&view=rev
Log:
PR c++/60374
* pt.c (coerce_template_parms): Check that the pack expansion
pattern works with the first matching parameter.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic154.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic155.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.7.4   |4.9.0

--- Comment #1 from Jason Merrill  ---
Fixed for 4.9.

[Bug libstdc++/60734] New: Undefined behavior in g++-v4/bits/stl_tree.h

[trippels at gcc dot gnu.org]

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

Bug ID: 60734
   Summary: Undefined behavior in g++-v4/bits/stl_tree.h
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

While debugging a gold linker issue I came across the following
-fsanitize=undefined runtime error:

/usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.0/include/g++-v4/bits/stl_tree.h:741:25:
runtime error: downcast of address 0x7fff4c8e1d80 with insufficient space for
an object of type '_Rb_tree_node,
gold::Output_segment *> >'
0x7fff4c8e1d80: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  d0 2c 8d 02 00 00 00 00  10 2d 8d 02 00
00 00 00  50 2d 8d 02
  ^ 

  iterator
  end() _GLIBCXX_NOEXCEPT
  { return iterator(static_cast<_Link_type>(&this->_M_impl._M_header)); }

The following message: 
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031213.html
also points to the issue.

Quote:
» _M_header is an _Rb_tree_node_base, which is smaller than an
_Rb_tree_node<_Tp>. Usually, this would be OK -- you can reinterpret_cast
between pointers of different types pretty much arbitrarily -- but because
_Rb_tree_node_base is a base class of _Rb_tree_node<_Tp>, this is a
static_cast, and the ruling wording is 5.2.9/11, which says " If the
prvalue of type “pointer to cv1 B” points
to a B that is actually a subobject of an object of type D, the resulting
pointer points to the enclosing object of type D. Otherwise, the behavior
is undefined."

We've managed to prove that the prvalue of type "pointer to
_Rb_tree_node_base" is not, in fact, a subobject of type
"_Rb_tree_node<_Tp>", because there's not enough room in the allocated
storage for an object of that type at that address. So we've determined
that the behavior is undefined.

This is a bug in libstdc++. The fix is to use reinterpret_cast instead of
static_cast in the definition of 'end'.«

And indeed this fixes the issue for me.

[Bug tree-optimization/60733] ICE by LTO on valid code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #1 from Zhendong Su  ---
Here is a variant that causes an ICE even without LTO. 

$ 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 20140401 (experimental) [trunk revision 208971] (GCC) 
$ 
$ gcc-4.8 -O3 small2.c; a.out
$ 
$ gcc-trunk -O3 small2.c 
small2.c: In function ‘main’:
small2.c:11:1: error: definition in block 12 follows the use
 main ()
 ^
for SSA_NAME: _64 in statement:
slsr_125 = _64 * 65535;
small2.c:11:1: internal compiler error: verify_ssa failed
0xb0b64b verify_ssa(bool)
../../gcc-trunk/gcc/tree-ssa.c:1096
0x8ae43c execute_function_todo
../../gcc-trunk/gcc/passes.c:1854
0x8aed93 execute_todo
../../gcc-trunk/gcc/passes.c:1887
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.
$   


--


int a, d, e, f, g, h, i, j, k;
unsigned short b;

short
fn1 (int p1, int p2)
{
  return p1 * p2;
}

int
main ()
{
  for (; a; a--)
{
  int l = 0;
  if (f >= 0)
{
  for (; h;)
e = 0;
  for (; l != -6; l--)
{
  j = fn1 (b--, d);
  for (g = 0; g; g = 1)
;
  k = e ? 2 : 0;
}
  i = 0;
  for (;;)
;
}
}
  d = 0;
  return 0;
}

[Bug tree-optimization/60733] New: ICE by LTO on valid code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 60733
   Summary: ICE by LTO on valid code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O3 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 20140401 (experimental) [trunk revision 208971] (GCC) 
$ 
$ gcc-trunk -O3 small.c; a.out
$ gcc-4.8 -flto -O3 small.c; a.out
$ 
$ gcc-trunk -flto -O3 small.c
small.c: In function ‘main’:
small.c:12:1: error: definition in block 10 follows the use
 main ()
 ^
for SSA_NAME: _83 in statement:
slsr_184 = _83 * 65535;
small.c:12:1: internal compiler error: verify_ssa failed
0xa4b70b verify_ssa(bool)
../../gcc-trunk/gcc/tree-ssa.c:1096
0x7ee4fc execute_function_todo
../../gcc-trunk/gcc/passes.c:1854
0x7eee53 execute_todo
../../gcc-trunk/gcc/passes.c:1887
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
$ 


-


int a, d, e, f, g, h, i, j, k, l;

unsigned short b;

short
fn1 (int p1, int p2)
{
  return p1 * p2;
}

int
main ()
{
  for (; a; a--)
{
  int m = 0;
  if (h)
{
  for (; i;)
{
  h++;
  e = 0;
  for (;;)
;
}
  for (; m != -6; m--)
{
  int n[] = {};
  k = fn1 (b--, d);
  for (g = 0; g; g = 1)
;
  l = e ? n[0] : 0;
  f ^= 1;
}
  j = 0;
  for (;;)
;
}
}
  d = 0;
  return 0;
}

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
There's a handful of these that need fixing in the ARM backend, some for the
'M' constraint others for 'I'.

Could you use satisfies_constraint_M and satisfies_constraint_I on the operand?
 At least that way the constraint and the predicate are 100% checking the same
thing.

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/60495] [4.9 Regression] ICE: in fold_convert_loc, at fold-const.c:1994

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #5 from Mikael Morin  ---
(In reply to Tobias Burnus from comment #4)
> Looks similar to PR60495;

Certainly; this _is_ PR60495. :-)

[Bug c++/60642] Unclear diagnostic with invalid use of abi_tag attribute on explicit instantiation

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for 4.9.  The compiler will now just warn that the attribute on the
explicit instantiation is ignored, and correctly emit the tag on
instantiations.

[Bug c++/60708] [4.8 Regression] An array temporary causes an ICE in gimplify

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.8/4.9 Regression] An |[4.8 Regression] An array
   |array temporary causes an   |temporary causes an ICE in
   |ICE in gimplify |gimplify

--- Comment #5 from Jason Merrill  ---
Fixed in 4.9 so far.

[Bug c++/60713] [4.8 regression] ICE in iterative_hash_expr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.8/4.9 regression] ICE in |[4.8 regression] ICE in
   |iterative_hash_expr |iterative_hash_expr

--- Comment #3 from Jason Merrill  ---
Fixed for 4.9 so far.

[Bug c++/60708] [4.8/4.9 Regression] An array temporary causes an ICE in gimplify

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Apr  1 19:14:00 2014
New Revision: 208996

URL: http://gcc.gnu.org/viewcvs?rev=208996&root=gcc&view=rev
Log:
PR c++/60708
* call.c (build_array_conv): Call complete_type.

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

[Bug c++/60713] [4.8/4.9 regression] ICE in iterative_hash_expr

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Apr  1 19:13:50 2014
New Revision: 208995

URL: http://gcc.gnu.org/viewcvs?rev=208995&root=gcc&view=rev
Log:
PR c++/60713
* typeck2.c (PICFLAG_SIDE_EFFECTS): New.
(picflag_from_initializer): Return it.
(process_init_constructor): Handle it.

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

[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11

[dave.anglin at bell dot net]

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

--- Comment #8 from dave.anglin at bell dot net ---
On 4/1/2014 2:17 PM, ccoutant at google dot com wrote:
> Ah, right. See PR 54499 and this thread:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00706.html
I think I see what's needed in arm.c.

[Bug target/378] [AIX] gcc cannot compile huge c file

[Doug at CSFi dot com]

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

--- Comment #12 from Doug Dawson  ---
(In reply to David Edelsohn from comment #11)
> Recent releases of GCC are built with linker options to allow larger data
> section. Are the user process limits (ulimit) set large enough?  One could
> rebuild GCC cc1 and cc1plus with even larger -bmaxdata value (or patch the
> binary with a larger value), but it's not clear which limit is hit.

Current ulimit values:

core file size  (blocks, -c) 1048575
data seg size   (kbytes, -d) 262144
file size   (blocks, -f) 2097151
max memory size (kbytes, -m) 32768
open files  (-n) 2000
pipe size(512 bytes, -p) 64
stack size  (kbytes, -s) 131072
cpu time   (seconds, -t) unlimited
max user processes  (-u) unlimited
virtual memory  (kbytes, -v) unlimited


I changed the ulimits below, but had the same results. Note that this source
compiles as 32 Bit on AIX 5.3 using 'gcc version 4.2.4'.

ulimit -d 393216
ulimit -m 65536
ulimit -s 262144
ulimit -n 4000

/tmp//ccZ4WBed.s: line 2939315: 1252-171 The displacement must be greater than
or equal to
-32768 and less than or equal to 32767.

When you say rebuild GCC cc1/cc1plus with even larger -bmaxdata, are you
refering to the AIX environmental 'export LDR_CNTRL=MAXDATA=0x5000'? Is
this the recommended value?

[Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[dominiq at lps dot ens.fr]

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

Bug ID: 60732
   Summary: FAIL: g++.dg/ext/altivec-7.C -std=*  scan-assembler
_Z3fooDv*
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: brooks at gcc dot gnu.org, iains at gcc dot gnu.org,
mikestump at comcast dot net
  Host: powerpc*-*-darwin*
Target: powerpc*-*-darwin*
 Build: powerpc*-*-darwin*

The test g++.dg/ext/altivec-7.C has started to fail on powerpc-apple-darwin9
after r203469. The failures are silenced with the following patch

--- ../_gcc_clean/gcc/testsuite/g++.dg/ext/altivec-7.C2013-10-13
00:58:24.0 +0200
+++ gcc/testsuite/g++.dg/ext/altivec-7.C2014-02-20 13:57:47.0 +0100
@@ -2,6 +2,7 @@
 /* { dg-do compile { target powerpc*-*-* } } */
 /* { dg-require-effective-target powerpc_altivec_ok } */
 /* { dg-options "-maltivec" } */
+/* { dg-additional-options "-fabi-version=0" { target powerpc*-*-darwin* } }
*/

 #include 

Is there any reason why -fabi-version=0 is not the default on
powerpc*-*-darwin*?

[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11

[ccoutant at google dot com]

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

--- Comment #7 from ccoutant at google dot com ---
> but the change is no longer in the current 4.9 code.

Ah, right. See PR 54499 and this thread:

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00706.html

-cary

[Bug c++/60708] [4.8/4.9 Regression] An array temporary causes an ICE in gimplify

[jason at gcc dot gnu.org]

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

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 debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net ---
On 4/1/2014 1:04 PM, ccoutant at gcc dot gnu.org wrote:
> The patch that this test case was part of was supposed to fix that problem by
> adding a call to debug_hooks->source_line from assemble_thunk.
The patch to cgraphunit.c added the call to debug_hooks->source_line:

diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index a6591b5..2dd0871 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1381,6 +1381,10 @@ assemble_thunk (struct cgraph_node *node)
init_function_start (thunk_fndecl);
cfun->is_thunk = 1;
assemble_start_function (thunk_fndecl, fnname);
+  (*debug_hooks->source_line) (DECL_SOURCE_LINE (thunk_fndecl),
+  DECL_SOURCE_FILE (thunk_fndecl),
+  /* discriminator */ 0,
+  /* is_stmt */ 1);

targetm.asm_out.output_mi_thunk (asm_out_file, thunk_fndecl,
fixed_offset, virtual_value, alias);

but the change is no longer in the current 4.9 code.  Maybe the call 
needs to be
added to pa_asm_output_mi_thunk.

[Bug c++/60713] [4.8/4.9 regression] ICE in iterative_hash_expr

[jason at gcc dot gnu.org]

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

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++/60642] Unclear diagnostic with invalid use of abi_tag attribute on explicit instantiation

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Apr  1 17:49:38 2014
New Revision: 208992

URL: http://gcc.gnu.org/viewcvs?rev=208992&root=gcc&view=rev
Log:
PR c++/60642
* decl2.c (is_late_template_attribute): Don't defer abi_tag.
* mangle.c (write_unqualified_name): Fix abi_tag on templates.
* pt.c (get_template_info): Handle NAMESPACE_DECL.
(most_general_template): Handle more kinds of template.
* tree.c (handle_abi_tag_attribute): Ignore abi_tag on template
instantiations and specializations.

Added:
trunk/gcc/testsuite/g++.dg/abi/abi-tag6.C
trunk/gcc/testsuite/g++.dg/abi/abi-tag7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/cp/mangle.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/g++.dg/abi/abi-tag3.C

[Bug ipa/60727] ICE in ipcp_verify_propagated_values, at ipa-cp.c:892

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
OK, the bit is actually calculated when streaming the node out (ugh)
in the following way:

  bp_pack_value (&bp, tag == LTO_symtab_analyzed_node
 && symtab_get_symbol_partitioning_class (node) == SYMBOL_PARTITION
 && (reachable_from_other_partition_p (node, encoder)
 || referenced_from_other_partition_p (&node->ref_list,
   encoder)), 1);

and with the patch, reachable_from_other_partition_p returns true
because it goes over all callers and if it does not find one in the
encoder it assumes it is in another partition.  The one caller is an
always_inline function that is not streamed after being squashed.

Honza told me on IRC that he would come up with a different patch to
fix the FORTIFY_SOURCE issue so I guess we don't need to fix this.
Otherwise we'd need to aff !flag_wpa or some such thing to the
condition.

[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|4.8.3   |4.7.4

--- Comment #7 from Jason Merrill  ---
OK, fixed for 4.7.4 as well.

[Bug libstdc++/41174] uncaught_exception always returns true

[jason at gcc dot gnu.org]

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

--- Comment #18 from Jason Merrill  ---
Author: jason
Date: Tue Apr  1 17:28:29 2014
New Revision: 208991

URL: http://gcc.gnu.org/viewcvs?rev=208991&root=gcc&view=rev
Log:
Core DR 475
PR c++/41174
PR c++/59224
* libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions.
* libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception)
(__cxa_allocate_exception): Don't set it here.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/eh/uncaught4.C
Modified:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/eh/uncaught1.C
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/libsupc++/eh_alloc.cc
branches/gcc-4_7-branch/libstdc++-v3/libsupc++/eh_throw.cc

[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Tue Apr  1 17:28:29 2014
New Revision: 208991

URL: http://gcc.gnu.org/viewcvs?rev=208991&root=gcc&view=rev
Log:
Core DR 475
PR c++/41174
PR c++/59224
* libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions.
* libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception)
(__cxa_allocate_exception): Don't set it here.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/eh/uncaught4.C
Modified:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/eh/uncaught1.C
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/libsupc++/eh_alloc.cc
branches/gcc-4_7-branch/libstdc++-v3/libsupc++/eh_throw.cc

[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11

[ccoutant at gcc dot gnu.org]

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

--- Comment #5 from Cary Coutant  ---
(In reply to Janis Johnson from comment #1)
> For arm-none-eabi the line that is recorded is 33 rather than 30.
> 
> I see from gcc-testresults that the test also fails for moxie-elf,
> bfin-rtems, and m32r-rtems.

The code at line 33 should be the constructor. Look for the thunks
_ZThn16_N1CD0Ev and _ZThn16_N1CD1Ev. They should have line 30, but I'd guess
the line number info is simply missing from those thunks. If they say line 33,
something else is wrong.

[Bug debug/55794] FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 and -std=gnu++11

[ccoutant at gcc dot gnu.org]

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

--- Comment #4 from Cary Coutant  ---
> On hppa64-hp-hpux11.11, I don't see any debug information at all unless
> I add "-g" to compile options.

The dg-options line adds -g2 -dA to the compile options.

In the assembly output you posted, the two thunks don't have any line number
info at all:

.globl_ZThn16_N1CD1Ev
.type_ZThn16_N1CD1Ev, @function
_ZThn16_N1CD1Ev:
.PROC
.CALLINFO FRAME=0,NO_CALLS
.ENTRY
b _ZN1CD2Ev
ldo -16(%r26),%r26
.EXIT
.PROCEND
.size_ZThn16_N1CD1Ev, .-_ZThn16_N1CD1Ev

.globl_ZThn16_N1CD0Ev
.type_ZThn16_N1CD0Ev, @function
_ZThn16_N1CD0Ev:
.PROC
.CALLINFO FRAME=0,NO_CALLS
.ENTRY
b _ZN1CD0Ev
ldo -16(%r26),%r26
.EXIT
.PROCEND
.size_ZThn16_N1CD0Ev, .-_ZThn16_N1CD0Ev

The patch that this test case was part of was supposed to fix that problem by
adding a call to debug_hooks->source_line from assemble_thunk.

Either the PA code generator doesn't go through assemble_thunk when generating
these thunks, or the call to debug_hooks->source_line is being ignored. Richard
Henderson expressed some concerns here:

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00312.html

I convinced him that the patch was OK, but perhaps he was right, and something
more is needed for PA.

[Bug c++/60731] New: dynamic library not getting reinitialized on multiple calls to dlopen()

[tim.moloney at mrsl dot com]

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

Bug ID: 60731
   Summary: dynamic library not getting reinitialized on multiple
calls to dlopen()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.moloney at mrsl dot com

Created attachment 32518
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32518&action=edit
Example showing failure to initialize a dynamic library after multiple calls to
dlopen().

If a dynamic library is loaded multiple times via dlopen(), subsequent loads do
not correctly initialize static variables under the following conditions:
1) A class/struct with a constructor
2) with an inlined function
3) containing a static variable.
Please run the attached example.
  # tar xf gcc_static_issue.tgz
  # cd gcc_static_issue
  # make
  # ./test_static
  Expected behavior (as on RHEL5, g++ 4.1.2):
  Type 'q' to exit or enter to reload/run the DLL
  count:1

  count:1

  count:1

  count:1

  count:1
  q
  #
Actual behavior (as on RHEL6 and RHEL7beta, g++ 4.4.7 and 4.8.2, respectively):
  Type 'q' to exit or enter to reload/run the DLL
  count:1

  count:2

  count:3

  count:4

  count:5
  q
  #

[Bug target/60704] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10

[rth at gcc dot gnu.org]

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

--- Comment #5 from Richard Henderson  ---
Author: rth
Date: Tue Apr  1 16:39:18 2014
New Revision: 208990

URL: http://gcc.gnu.org/viewcvs?rev=208990&root=gcc&view=rev
Log:
PR target/60704

* gcc.dg/pr60704.c: New file.

Added:
trunk/gcc/testsuite/gcc.dg/pr60704.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/60727] ICE in ipcp_verify_propagated_values, at ipa-cp.c:892

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
What happens is that we do not remove an unreachable cgraph_node.  We
don't do it because the node has used_from_other_partition set which I
assume is always bogus at the beginning of WPA (moreover, the node is
also local).  I'll have a look why exactly that happens.

[Bug target/60704] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug target/378] [AIX] gcc cannot compile huge c file

[dje at gcc dot gnu.org]

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

--- Comment #11 from David Edelsohn  ---
Recent releases of GCC are built with linker options to allow larger data
section. Are the user process limits (ulimit) set large enough?  One could
rebuild GCC cc1 and cc1plus with even larger -bmaxdata value (or patch the
binary with a larger value), but it's not clear which limit is hit.

[Bug target/378] [AIX] gcc cannot compile huge c file

[Doug at CSFi dot com]

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

Doug Dawson  changed:

   What|Removed |Added

 CC||Doug at CSFi dot com

--- Comment #10 from Doug Dawson  ---
Has any progress been made on this bug? It still affects AIX 6.1 on gcc Version
4.7.2 compiling a 64 Bit gSOAP generated source.

AIX:doug:1> oslevel
6.1.0.0
AIX:doug:1> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/freeware/libexec/gcc/powerpc-ibm-aix6.1.0.0/4.7.2/lto-wrapper
Target: powerpc-ibm-aix6.1.0.0
Configured with: configure --prefix=/opt/freeware --enable-languages=c,c++
--enable-threads=posix --disable-nls --with-gmp=/opt/freeware
--with-mpfr=/opt/freeware --with-mpc=/opt/freeware --disable-libstdcxx-pch
Thread model: aix
gcc version 4.7.2 (GCC)
AIX:doug:1>

[Bug ada/60730] 'Round of a fixed point type incorrectly truncates its operand instead of rounding it

[georggcc at googlemail dot com]

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

Georg  changed:

   What|Removed |Added

 CC||georggcc at googlemail dot com

--- Comment #1 from Georg  ---
Don't know if #41416 is related in any way, but the subject seems similar.

[Bug ada/60730] New: 'Round of a fixed point type incorrectly truncates its operand instead of rounding it

[georggcc at googlemail dot com]

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

Bug ID: 60730
   Summary: 'Round of a fixed point type incorrectly truncates its
operand instead of rounding it
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: georggcc at googlemail dot com

Created attachment 32517
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32517&action=edit
full program text

The program below raises, but should not; LRM 3.5.10 says
that Centi'Round should round away from 0 in the case
presented here.

The program attached to this report tries to reflect the
discussion in comp.lang.ada that started on 22nd of Jan 2014,
"How to round to the nearest fixed-point value".
The effect seen has been classified as a compiler bug: the
program should run as is, with no output. Instead, it raises
Program_Error because the value of 0.999, supposedly
rounded to 3 digits in `Rounded`, is not 1.00, but 0.99. 

$ gnatmake -gnatv -gnatwa round_decimal
gcc -c -gnatv -gnatwa round_decimal.adb

GNAT 4.9.0 20140331 (experimental)
Copyright 1992-2014, Free Software Foundation, Inc.

Compiling: round_decimal.adb (source file time stamp: 2014-04-01 15:39:04)
 38 lines: No errors
gnatbind -x round_decimal.ali
gnatlink round_decimal.ali

$ ./round_decimal 

raised PROGRAM_ERROR : round_decimal.adb:35 explicit raise

[Bug preprocessor/60723] Line directives with incorrect system header flag

[nicholas.ormrod at hotmail dot com]

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

Nicholas  changed:

   What|Removed |Added

 CC||nicholas.ormrod at hotmail dot 
com

--- Comment #5 from Nicholas  ---
Thank you for the link, Manuel. This is my first contribution to gcc. I'll see
if I can follow your instructions.

As for the content of the patch, it fixes the second and more egregious error.
In and of itself, token-line inconsistency is not the end of the world; the
real problem is that the code that inserts the bad line directive has a bug.
Specifically, it uses the macro's source file to determine the callsite file's
properties. That is what the patch fixes.

I do not have a patch for the line inconsistency, which is one of the reasons
that I posted this to the bug forum.

[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills

[yvan.roux at linaro dot org]

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

--- Comment #11 from Yvan Roux  ---
Thanks for the analysis Vladimir, let me know if I can help you for the
validation.

[Bug c++/60716] gcc cannot detect static recursive function

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Manuel López-Ibáñez  ---
There is a patch in the duplicate, but it was problematic for some old reason
that I already forgot.

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

[Bug c++/32562] -Wunused doesn't warn about static function only called by itself.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from Manuel López-Ibáñez  ---
*** Bug 60716 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #10 from Vladimir Makarov  ---
(In reply to Yvan Roux from comment #9)
> the new command line is :
> 
> cc1 -O2 -fno-omit-frame-pointer -march=armv7-a  xfs_bmap_util.i

Thanks, Yvan.

The problem now is in a need to have 3 double regs reload pseudos and there are
no enough double regs even after spilling all pseudos living through the insn. 
Reload uses another insn alternative with matching constraint which needs only
2 double reg reload pseudos.

So the solution is to force LRA to choose the same insn alternative as reload
does.  As it is a very sensitive part of LRA, any change here needs a lot
testing and benchmarking.  I hope to find a solution, test it and commit it by
Friday.

[Bug target/60704] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
Author: rth
Date: Tue Apr  1 14:40:27 2014
New Revision: 208989

URL: http://gcc.gnu.org/viewcvs?rev=208989&root=gcc&view=rev
Log:
PR target/60704

* config/i386/i386.md (*float2_sse): Leave the second
alternative enabled before register allocation.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

[Bug c++/60729] Compiler failure for combination of -ftrapv and -O3: compiler error: in prepare_cmp_insn

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-04-01
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.  The issue is that we vectorize the abs() but fail to provide
a negv_optab for V2DFmode and the fallback expansion fails as well
(this path isn't able to handle the vector case at all).

Issue with expand_abs_nojump which uses absv_optab for FP modes.

Index: gcc/optabs.c
===
--- gcc/optabs.c(revision 208988)
+++ gcc/optabs.c(working copy)
@@ -3384,7 +3384,8 @@ expand_abs_nojump (enum machine_mode mod
 {
   rtx temp;

-  if (! flag_trapv)
+  if (GET_MODE_CLASS (mode) != MODE_INT
+  || ! flag_trapv)
 result_unsignedp = 1;

   /* First try to do it with a special abs instruction.  */
@@ -3407,7 +3408,8 @@ expand_abs_nojump (enum machine_mode mod
 {
   rtx last = get_last_insn ();

-  temp = expand_unop (mode, neg_optab, op0, NULL_RTX, 0);
+  temp = expand_unop (mode, result_unsignedp ? neg_optab : negv_optab,
+ op0, NULL_RTX, 0);
   if (temp != 0)
temp = expand_binop (mode, smax_optab, op0, temp, target, 0,
 OPTAB_WIDEN);
@@ -3449,7 +3451,8 @@ expand_abs (enum machine_mode mode, rtx
 {
   rtx temp, op1;

-  if (! flag_trapv)
+  if (GET_MODE_CLASS (mode) != MODE_INT
+  || ! flag_trapv)
 result_unsignedp = 1;

   temp = expand_abs_nojump (mode, op0, target, result_unsignedp);

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-01
 CC||mpolacek at gcc dot gnu.org
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
It adds the default case at the end of the switch so we can jump over the whole
switch body.  But it should do so only if the labels cover the whole range of
the controlling expression of the switch.  Here the switch label seemingly
covers the whole range of the enum, but TYPE_MAX_VALUE of the enum E is
UINT_MAX, while the high value of the case label is 0.

[Bug fortran/60128] [4.8 Regression] Wrong ouput using en edit descriptor

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|[4.8/4.9 Regression] Wrong  |[4.8 Regression] Wrong
   |ouput using en edit |ouput using en edit
   |descriptor  |descriptor

--- Comment #64 from Dominique d'Humieres  ---
Author:dominiq
Date: Tue Apr 1 09:21:53 2014
New Revision: 208979

URL: http://gcc.gnu.org/viewcvs?rev=208979&root=gcc&view=rev
Log:
2014-04-01  Dominique d'Humieres  

libfortran/60128
* gfortran.dg/fmt_en.f90: Skip unsupported rounding tests.
XFAIL for i?86-*-solaris2.9* and hppa*-*-hpux*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/fmt_en.f90

[Bug c++/60729] Compiler failure for combination of -ftrapv and -O3: compiler error: in prepare_cmp_insn

[rppawlo at sandia dot gov]

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

--- Comment #2 from rppawlo at sandia dot gov ---
Created attachment 32516
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32516&action=edit
error file generated from compiler failure

[Bug c++/60729] Compiler failure for combination of -ftrapv and -O3: compiler error: in prepare_cmp_insn

[rppawlo at sandia dot gov]

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

--- Comment #1 from rppawlo at sandia dot gov ---
Created attachment 32515
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32515&action=edit
output file generated with -save-temps

[Bug c++/60729] New: Compiler failure for combination of -ftrapv and -O3: compiler error: in prepare_cmp_insn

[rppawlo at sandia dot gov]

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

Bug ID: 60729
   Summary: Compiler failure for combination of -ftrapv and -O3:
compiler error: in prepare_cmp_insn
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rppawlo at sandia dot gov

Created attachment 32514
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32514&action=edit
test file

Hi,

I'm running stock Ubuntu 13.10 and get a g++ compiler error when using a
certain commbination of compiler options.  

The attached file reproduces the bug:

*BEGIN FILE***

// This test generates an inernal compiler failure in g++ 4.8.1 on
// ubuntu 13.10.  The combination of -O3 and -ftrapv causes the issue.
// You can drop to -O2 or remove -ftrapv to fix.

// The following compile works:
// g++ -O3 -c test.cpp
// g++ -O2 -ftrapv -c test.cpp

// The following compile fails:
// g++ -ftrapv -O3 -c test.cpp

#include 

void doSomething(int dim, double *Y, double *A) 
{
  for (int k=0; k for instructions.
Preprocessed source stored into /tmp/cccvQgai.out file, please attach this to
your bugreport.
rppawlo@drekar:~$


Here's some info about my machine/environment:

rppawlo@drekar:~$ g++ --version
g++ (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rppawlo@drekar:~$ uname -a
Linux drekar 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux

[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
This one has them all, in addition to fixing a real problem:

http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00016.html

[Bug tree-optimization/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||xfail
   Priority|P1  |P3

[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Richard Biener from comment #9)
> (In reply to Richard Biener from comment #8)
> > *** Bug 60721 has been marked as a duplicate of this bug. ***
> 
> See there for another proposed fix to retain per-call 'leaf' (well,
> no-abnormal-goto) status.

Btw, similar to this flag a flag for a per-call 'noreturn' status should
be added as well, getting rid of that MODIFIED_NORETURN_CALLS red herring
on the way (basically defer committing 'noreturn' from a decl to all callers
until a suitable time).  I suppose different 'noreturn' status in LTO units
can also cause a similar issue where a (no longer after merging) noreturn
call ending BB fails to have a fallthru edge.

[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Created attachment 32513
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32513&action=edit
Miscompiled run time testcase

(In reply to Jakub Jelinek from comment #7)
> 
> I still see the old testcase only there ;).

Yeah, I forgot to refresh the patch, but I do have it in my copy.  I'm
also adding this one.

[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to Richard Biener from comment #8)
> *** Bug 60721 has been marked as a duplicate of this bug. ***

See there for another proposed fix to retain per-call 'leaf' (well,
no-abnormal-goto) status.

[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
*** Bug 60721 has been marked as a duplicate of this bug. ***

[Bug lto/60721] xcoral fails to build with LTO: internal compiler error: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Dup.

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

[Bug lto/60721] xcoral fails to build with LTO: internal compiler error: verify_flow_info failed

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #5 from Martin Jambor  ---
This is a duplicate of PR 60449.  I'm not sure which one we want to
close as a duplicate though.  In that PR 60449 comment 6, Richi wrote:

"OTOH, why do we have to merge the decls/cgraph nodes at all?  Can't we simply
make them aliases if tree merging decides the decls are not equal?"

which might also be a nice fix.

[Bug go/60728] recover() should not work in recursive deferred fucntions

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

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

--- Comment #1 from Dominik Vogt  ---
A fix for bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 should also
take care of this one.

[Bug go/60728] New: recover() should not work in recursive deferred fucntions

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 60728
   Summary: recover() should not work in recursive deferred
fucntions
   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 an email discussion between me and with Ian Lance Taylor about the
function statements.cc:build_thunk():

Ian Lance Taylor wrote:
> On Fri, Mar 28, 2014 at 3:37 AM, Dominik Vogt  wrote:
> > (First note that I think there's a bug in the current code with
> > recursive calls of functions with recover.  Consider this:
> >
> >   func f() {
> > defer g(0);
> > ...
> >   }
> >
> >   func g(n int) {
> > if n == 0 {
> >   g(1)
> > } else {
> >   recover()
> > }
> >   }
> >
> > With the current logic the recursive call of g() would recover
> > (__go_gan_recover returns true), but it shouldn't because it's not
> > called directly.  The following sketch takes care of that
> > situation.)
>
> Good point.

[Bug lto/60721] xcoral fails to build with LTO: internal compiler error: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Created attachment 32512
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32512&action=edit
patch

Fixed for example with the following.

[Bug lto/60721] xcoral fails to build with LTO: internal compiler error: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-01
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Reduced testcase:

> cat t1.i
extern char *getenv (const char *);
int main ()
{
  getenv("");
}
> cat t2.c
#include 
extern char *getenv (const char *) __attribute__ ((__leaf__));
int init_smac()
{
  jmp_buf come_back;
  getenv("");
  return setjmp (come_back);
}
> ./xgcc -B. t1.i t2.c -flto
t2.c: In function 'init_smac':
t2.c:3:5: error: control flow in the middle of basic block 2
 int init_smac()
 ^
t2.c:3:5: error: control flow in the middle of basic block 2
t2.c:3:5: internal compiler error: verify_flow_info failed

[Bug middle-end/60726] [AArch64] pr40074.c regression after intrinsics a53 tuning

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
No problem, better safe than sorry :)

[Bug middle-end/60726] [AArch64] pr40074.c regression after intrinsics a53 tuning

[yvan.roux at linaro dot org]

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

--- Comment #4 from Yvan Roux  ---
I just find the logs from the build farm, and it is indeed a qemu uncaught
signal. Sorry for the false alert !

[Bug ipa/60727] ICE in ipcp_verify_propagated_values, at ipa-cp.c:892

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Can be reproduced with http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01237.html
ontop of r208807 and the following reduced testcase:

typedef long unsigned int size_t;
class JSCell;
class JSObject;
class X;
class JSValue {
public:
JSValue(JSCell* ptr);
};
class MarkStack{ };
class I { };
class JSCell {
friend class JSObject;
virtual JSObject* toObject() const;
bool fastGetOwnX(const I& propertyName, X&);
virtual bool getOwnX(const I& propertyName, X&);
};
class X {
public:
typedef JSValue (*GetValueFunc)(const I&, const X&);
void setValueSlot(JSValue, JSValue*, size_t) { m_getValue = 0; }
GetValueFunc m_getValue;
};
class JSObject : public JSCell {
friend class JSCell;
virtual void markChildren(MarkStack&);
bool getX(const I& propertyName, X&);
virtual bool getOwnX(const I& propertyName, X&);
bool inlineGetOwnX(const I& propertyName, X&);
};
inline __attribute__((__always_inline__)) bool
JSObject::inlineGetOwnX(const I& propertyName, X& slot)
{
slot.setValueSlot(this, 0, 0);
}
inline __attribute__((__always_inline__)) bool
JSObject::getOwnX(const I& propertyName, X& slot)
{
return inlineGetOwnX(propertyName, slot);
}
inline __attribute__((__always_inline__)) bool
JSCell::fastGetOwnX(const I& propertyName, X& slot)
{
return getOwnX(propertyName, slot);
}
inline __attribute__((__always_inline__)) bool
JSObject::getX(const I& propertyName, X& slot)
{
this->fastGetOwnX(propertyName, slot);
}
bool JSCell::getOwnX(const I& identifier, X& slot)
{
JSObject* object = toObject();
object->getX(identifier, slot);
}

I suppose that patch either pulls the bodies from IPA-CP at some bogus
time or ends up with cgraph nodes confusing IPA-CP.  Needs -flto only
because the patch changes the -flto path only (as opposed to Honzas proposed
change in that thread that doesn't fix the issue).  Somehow the patch
doesn't trigger the same issue on trunk though.

[Bug middle-end/60726] [AArch64] pr40074.c regression after intrinsics a53 tuning

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Passes for me on a native aarch64-unknown-linux-gnu test run with r208953,
which contains the tuning patches.

Are you sure this is not an environment issue with a model or something?

[Bug target/60604] [4.9 Regression] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #14 from rsandifo at gcc dot gnu.org  
---
Patch applied.

[Bug target/60604] [4.9 Regression] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)

[rsandifo at gcc dot gnu.org]

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

--- Comment #13 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Apr  1 10:38:19 2014
New Revision: 208984

URL: http://gcc.gnu.org/viewcvs?rev=208984&root=gcc&view=rev
Log:
gcc/
PR rtl-optimization/60604
* recog.c (general_operand): Incorporate REG_CANNOT_CHANGE_MODE_P
check from register_operand.
(register_operand): Redefine in terms of general_operand.
(nonmemory_operand): Use register_operand for the non-constant cases.

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

[Bug middle-end/60726] [AArch64] pr40074.c regression after intrinsics a53 tuning

[yvan.roux at linaro dot org]

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

--- Comment #2 from Yvan Roux  ---
I don't observe the regression in aarch64-none-elf on my side too. I'm looking
for the configuration...

[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test

[dominiq at gcc dot gnu.org]

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

--- Comment #16 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Apr  1 10:19:06 2014
New Revision: 208983

URL: http://gcc.gnu.org/viewcvs?rev=208983&root=gcc&view=rev
Log:
2014-04-01  Dominique d'Humieres 
Rainer Orth  

PR libgcj/55637
* testsuite/libjava.lang/sourcelocation.xfail: New file.


Added:
branches/gcc-4_8-branch/libjava/testsuite/libjava.lang/sourcelocation.xfail
Modified:
branches/gcc-4_8-branch/libjava/ChangeLog

[Bug middle-end/60726] [AArch64] pr40074.c regression after intrinsics a53 tuning

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Can't reproduce with an aarch64-none-elf compiler, now building an
aarch64-none-linux-gnu one.

What is the failing configuration?

[Bug tree-optimization/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

[amker at gcc dot gnu.org]

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

--- Comment #12 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Apr  1 09:56:29 2014
New Revision: 208980

URL: http://gcc.gnu.org/viewcvs?rev=208980&root=gcc&view=rev
Log:

PR target/60363
* gcc.target/tree-ssa/ssa-dom-thread-4.c: Xfail for
logical_op_short_circuit targets.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c

[Bug preprocessor/60723] Line directives with incorrect system header flag

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
Patches go to the gcc-patches mailing list for review. You will also need a
testcase formatted for inclusion on the testsuite and test your patch against
the GCC testsuite. See also: http://gcc.gnu.org/contribute.html

> In a function-like macro expansion, regular tokens are line-marked as being
> expanded at the opening parenthesis, while builtins are line-marked as being
> expanded at the closing parenthesis (both of these choices are reasonable,
> though the inconsistency is probably a design flaw). When a non-builtin
> follows a builtin in a multiline macro call, the line numbers of the tokens
> are inconsistent, forcing a line directive to be inserted.

I don't see how your patch fixes this inconsistency.

[Bug ipa/60727] ICE in ipcp_verify_propagated_values, at ipa-cp.c:892

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
eventually this is already fixed (cannot reproduce in my development tree - but
that has a load of patches, including LTO ones).

[Bug ipa/60727] New: ICE in ipcp_verify_propagated_values, at ipa-cp.c:892

[rguenth at gcc dot gnu.org]

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

Bug ID: 60727
   Summary: ICE in ipcp_verify_propagated_values, at ipa-cp.c:892
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org

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

Compiling libqt4 with -flto and r208807 yields

> g++-4.9 JSCell.ii -flto -O2 -fvisibility=hidden -shared -nostdlib
lto1: internal compiler error: in ipcp_verify_propagated_values, at
ipa-cp.c:892
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: g++-4.9 returned 1 exit status
/usr/lib64/gcc/x86_64-suse-linux/4.9/../../../../x86_64-suse-linux/bin/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug debug/38757] gcc does not emit DW_LANG_C99

[mark at gcc dot gnu.org]

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

--- Comment #5 from Mark Wielaard  ---
Patch has been discussed on the patches list a couple of times in the past, but
not yet applied:

http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00858.html
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00991.html

An updated version of the patch is also available as part of the Fedora GCC
package:

http://pkgs.fedoraproject.org/cgit/gcc.git/tree/gcc48-pr38757.patch

[Bug regression/60726] New: [AArch64] pr40074.c regression after intrinsics a53 tuning

[yvan.roux at linaro dot org]

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

Bug ID: 60726
   Summary: [AArch64] pr40074.c regression after intrinsics a53
tuning
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yvan.roux at linaro dot org

Hi,

there is a regression on aarch64-none-linux-gnu for pr40074.c after
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=208910

Passed now fails  [PASS => FAIL]:
  gcc.dg/vect/pr40074.c -flto -ffat-lto-objects execution test
  gcc.dg/vect/pr40074.c execution test

[Bug debug/38757] gcc does not emit DW_LANG_C99

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #4 from Mark Wielaard  ---
DWARFv4 did add several new DW_LANG codes to distinquish between Ada versions.
DWARFv5 will likely add DW_LANG codes for C++03, C++11 and C11.

[Bug libstdc++/60711] basic_ostringstream,basic_ostream,u16string,char16_t do not work together

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #14 from Jonathan Wakely  ---
(In reply to Jim Michaels from comment #10)
> I am just saying something smells like a compiler bug here.

"I don't understand C++" is not a compiler bug.

[Bug c++/60714] comments in template instantiation are interpreted

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
std::basic_stringbuf is not a type, it's a template.

std::basic_stringbuf is a type, so std::basic_stringbuf::int_type
would be a type

[Bug libstdc++/60724] std::ostream o; gives protected errors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jim Michaels from comment #0)
> ostream-bug.cpp:3:18: error: within this context
>  std::ostream o;
>   ^
> did the c++ standard change drastically for iostreams in the last month?

No, it's always been like that.

std::ostream provides an interface, not a concrete implementation, so you
cannot just declare an ostream and expect it to work (where would it write
to?!)

std::ostream is meant to be used as a base class of conrete stream types, such
as ofstream (which writes to a file) or ostringstream (which writes to a memory
buffer).

> if you are going to quote me to use a streambuf or stringbuf, those are
> protected too.

For the same reason. You need to use a derived streambuf, such as filebuf or
stringbuf, or write your own derived streambuf.


> if you are going to quote an example using a filebuf, I am
> not working with a file at this point. I just want to output strings.

Output to *where*?

If you want to write to the console, then use std::cout, or open a
std::ofstream to the relevant device (I think it's called "CON" in Windows).


(In reply to Jim Michaels from comment #4)
> problem is, those solutions seem to be copyrighted and made impossible to
> use for commercial purposes.

I have no idea what you're talking about, but it's irrelevant to GCC.

Please stop changing the resolution to FIXED, there is no GCC bug to fix, your
code is not valid C++, so your bug report is invalid.

GCC is correctly implementing the standard here, it is not the GCC project's
responsibility to fix the design of your program.

[Bug lto/60721] xcoral fails to build with LTO: internal compiler error: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
IMHO we need a flag on each gimple call whether that call instance is supposed
to be 'leaf' or not, similar to how we have noreturn and nothrow flags here.

[Bug c/60725] New: [-Wreturn-type] false positive in trivial switch

[skvadrik at gmail dot com]

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

Bug ID: 60725
   Summary: [-Wreturn-type] false positive in trivial switch
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skvadrik at gmail dot com

Created attachment 32510
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32510&action=edit
wreturn_false_positive.c

Given this program (see attachment):

  // wreturn_false_positive.c
  enum E { E1 };
  static inline int f1(enum E e) {
  switch (e) {
  case E1: return 1;
  }
  }
  int main () {
  f1(E1);
  return 0;
  }

gcc generates warning:

$ gcc -Wall wreturn_false_positive.c 
wreturn_false_positive.c: In function ‘f1’:
wreturn_false_positive.c:9:1: warning: control reaches end of non-void function
[-Wreturn-type]

If I compile with '-fdump-tree-all', I see that gcc adds 'default' case to
switch very early (in .gimple), and later it cannot get rid of that 'default'
path. Why does gcc add default case?

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
Hmm...
adding the option -fno-strict-aliasing generates correct code at -O2 and -O3.