[Bug lto/65536] LTO line number information garbled

[hubicka at gcc dot gnu.org]

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

--- Comment #47 from Jan Hubicka  ---
Author: hubicka
Date: Fri Mar 27 06:58:59 2015
New Revision: 221720

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

PR lto/65536
* lto-streamer.h (class lto_location_cache): New.
(struct data_in): Add location_cache.
(lto_input_location): Update prototype.
(stream_input_location_now): New.
* streamer-hooks.h (struct streamer_hooks): Make input_location to take
pointer to location.
(stream_input_location): Update.
* ipa-devirt.c: Include streamer-hooks.h and lto-streamer.h
(warn_odr): Apply location cache before warning.
(lto_input_location): Update prototype.
* gimple-streamer-in.c (input_phi, input_gimple_stmt):
Use stream_input_location_now.
* lto/lto.c (unify_scc): Revert location cache when unification
suceeded.
(lto_read_decls): Accept location cache after sucess;
apply location cache before calling debug hooks.
* lto-streamer-in.c (lto_location_cache::current_cache): New static
variable.
(lto_location_cache::cmp_loc): New function.
(lto_location_cache::apply_location_cache): New function.
(lto_location_cache::accept_location_cache): New function.
(lto_location_cache::revert_location_cache): New function.
(lto_location_cache::input_location): New function.
(lto_input_location): Do location caching.
(stream_input_location_now): New function.
(input_eh_region, input_struct_function_base): Use
stream_input_location_now.
(lto_data_in_create): use new.
(lto_data_in_delete): Use delete.
* tree-streamer-in.c (unpack_ts_block_value_fields,
unpack_ts_omp_clause_value_fields, streamer_read_tree_bitfields,
lto_input_ts_exp_tree_pointers): Update for cached location api.

Modified:
trunk/gcc/gimple-streamer-in.c
trunk/gcc/ipa-devirt.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer.h
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c
trunk/gcc/streamer-hooks.h
trunk/gcc/tree-streamer-in.c

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
The testcase contains one loop nest with 3 loops with iteration counts 500, so
the inner loop body is executed 125.000.000 times:
...
#define N 500

int X[2*N], Y[2*N], B[2*N];
int A[2*N][2*N], C[2*N][2*N];

int foo(void)
{
  int i, j, k;

  for (i = 0; i < N; i++)
{
  X[i] = Y[i] + 10;
  for (j = 0; j < N; j++)
{
  B[j] = A[j][N];
  for (k = 0; k < N; k++)
{
  A[j+1][k] = B[j] + C[j][k];
}
  Y[i+j] = A[j+1][N];
}
}

  return A[1][5]*B[6];
}
...

The testcase uses -ftree-parallelize-loops=4 -floop-parallelize-all, and we
parallelize the inner loop, which means we call __builtin_GOMP_parallel 250.000
times, to create 1.000.000 threads, which each handle 125 iterations.

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

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Created attachment 35158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35158&action=edit
reduced testcase

markus@x4 tmp % g++ -std=gnu++1y -flto -g -O2 -r -nostdlib tcp_client.ii
lto1: internal compiler error: Segmentation fault
0xa2766f crash_signal
../../gcc/gcc/toplev.c:383
0x10ed7b0 htab_hash_string
../../gcc/libiberty/hashtab.c:839
0x6e66df external_ref_hasher::hash(external_ref const*)
../../gcc/gcc/dwarf2out.c:7763
0x6e66df hash_table::find_slot(external_ref const*, insert_option)
../../gcc/gcc/hash-table.h:652
0x6e66df lookup_external_ref
../../gcc/gcc/dwarf2out.c:7791
0x6e6770 optimize_external_refs_1
../../gcc/gcc/dwarf2out.c:7829
0x6e6797 optimize_external_refs_1
../../gcc/gcc/dwarf2out.c:7833
0x6e6c06 optimize_external_refs
../../gcc/gcc/dwarf2out.c:7882
0x6e6e3d output_comp_unit
../../gcc/gcc/dwarf2out.c:9122
0x70ac89 dwarf2out_finish
../../gcc/gcc/dwarf2out.c:24800
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug lto/65536] LTO line number information garbled

[hubicka at gcc dot gnu.org]

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

--- Comment #48 from Jan Hubicka  ---
I run memory statistics with the cache and my patch. I will run stats with
cache w/o the libcpp patch tomorrow.  I would like to get this problem solved,
but perhaps we want to only track down the reason for wrong line numbers and do
more tuning next stage1 & backport.

I suppose I can implement checking that will lookup location after every insert
to double check lines are not garbled. Dropped columns are I guess acceptable
(it would be nice to drop the wrong carrets then)

So for memory use:
realloc_for_line_map is now at 1681: 0.9% of GGC memory use pre-IPA. This
is definitly improvement. Gimple streaming however push it up to 75497496:4.2%
I guess this suggest that caching blocks and gimple stmt locators would make a
lot of difference.

ltrans report 4194328: 5.4% post main decl streaming, but before bodies are
read in.

[Bug target/65593] [5 Regression] internal compiler error: in extract_insn, at recog.c:2343

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Looks similar to PR65560.

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Well, GOMP_parallel doesn't always create new threads, but still it has some
synchronization overhead etc.  IMNSHO the testcase should be scaled down for
the testsuite, IMHO lowering N to 100 would be in order.

[Bug middle-end/65595] New: [5 Regression] Linux kernel build failure: ICE: in as_a, at is-a.h:192

[trippels at gcc dot gnu.org]

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

Bug ID: 65595
   Summary: [5 Regression] Linux kernel build failure: ICE: in
as_a, at is-a.h:192
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org

trippels@gcc2-power8 linux-3.18.8 % cat libcxgbi.i
extern void *memcpy(void *, const void *, unsigned long);
struct in6_addr {
  struct {
int u6_addr32[4];
  };
};
struct foo {
  struct in6_addr daddr;
  struct in6_addr saddr;
} a;
extern void ip6_route_output(struct foo, int);
int b;
static void find_route_ipv6(struct in6_addr *p1) {
  if (p1)
memcpy(0, p1, sizeof(struct in6_addr));
  ip6_route_output(a, b);
}
void cxgbi_ep_connect() { find_route_ipv6(0); }

trippels@gcc2-power8 linux-3.18.8 % gcc -O2 -c libcxgbi.i
libcxgbi.i: In function ‘find_route_ipv6.constprop’:
libcxgbi.i:18:1: internal compiler error: in as_a, at is-a.h:192
 void cxgbi_ep_connect() { find_route_ipv6(0); }
 ^
0x100f16e3 as_a
../../gcc/gcc/is-a.h:192
0x1030ffb7 as_a
../../gcc/gcc/is-a.h:192
0x1030ffb7 cgraph_update_edges_for_call_stmt_node
../../gcc/gcc/cgraph.c:1524
0x1031045f cgraph_update_edges_for_call_stmt(gimple_statement_base*,
tree_node*, gimple_statement_base*)
../../gcc/gcc/cgraph.c:1588
0x108720a3 fold_marked_statements
../../gcc/gcc/tree-inline.c:4843
0x10884ebf tree_function_versioning(tree_node*, tree_node*,
vec*, bool, bitmap_head*, bool,
bitmap_head*, basic_block_def*)
../../gcc/gcc/tree-inline.c:5813
0x103229ef cgraph_materialize_clone
../../gcc/gcc/cgraphclones.c:1056
0x103229ef symbol_table::materialize_all_clones()
../../gcc/gcc/cgraphclones.c:1153
0x1031c3cb symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2326
0x1031ee67 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2444
0x1015d1c7 c_write_global_declarations()
../../gcc/gcc/c/c-decl.c:10801
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Patch to do so preapproved for trunk, if the testcase is still
auto-parallelized in that case.

[Bug middle-end/65595] [5 Regression] Linux kernel build failure: ICE: in as_a, at is-a.h:192

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Started with r221707.

[Bug target/65593] [5 Regression] internal compiler error: in extract_insn, at recog.c:2343

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug middle-end/65595] [5 Regression] Linux kernel build failure: ICE: in as_a, at is-a.h:192

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug c++/65592] internal compiler error: Segmentation fault when using non-existant enum class enumerator

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-27
 Ever confirmed|0   |1
  Known to fail||4.7.4, 4.8.3, 4.9.2, 5.0

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

[Bug c++/65591] G++ should use default constructor for {}-init when possible

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-27
 Ever confirmed|0   |1

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

[Bug ipa/65588] [5 Regression] lto1: internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-linux
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Keywords||lto
   Last reconfirmed||2015-03-27
  Component|lto |ipa
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|lto1: internal compiler |[5 Regression] lto1:
   |error: Segmentation fault   |internal compiler error:
   ||Segmentation fault
   Target Milestone|--- |5.0

--- Comment #3 from Richard Biener  ---
Confirmed with -O -flto.

Program received signal SIGSEGV, Segmentation fault.
0x00fe8b47 in assemble_undefined_decl (decl=0x768d7990)
at /space/rguenther/src/svn/trunk2/gcc/varasm.c:2079
2079  const char *name = XSTR (XEXP (DECL_RTL (decl), 0), 0);
(gdb) bt
#0  0x00fe8b47 in assemble_undefined_decl (decl=0x768d7990)
at /space/rguenther/src/svn/trunk2/gcc/varasm.c:2079
#1  0x00fff91f in symbol_table::output_variables (this=0x768d)
at /space/rguenther/src/svn/trunk2/gcc/varpool.c:741
#2  0x007b0e34 in symbol_table::compile (this=0x768d)
at /space/rguenther/src/svn/trunk2/gcc/cgraphunit.c:2368
#3  0x006ed92d in lto_main ()
at /space/rguenther/src/svn/trunk2/gcc/lto/lto.c:3483
#4  0x00c9acbb in compile_file ()
at /space/rguenther/src/svn/trunk2/gcc/toplev.c:594
#5  0x00c9d07e in do_compile ()
at /space/rguenther/src/svn/trunk2/gcc/toplev.c:2076
#6  0x00c9d2aa in toplev::main (this=0x7fffdba0, argc=25, 
argv=0x20e4320) at /space/rguenther/src/svn/trunk2/gcc/toplev.c:2174
#7  0x0161b127 in main (argc=25, argv=0x7fffdca8)
at /space/rguenther/src/svn/trunk2/gcc/main.c:39
(gdb) p debug_tree (decl)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x768d0690 precision
32 min  max 
pointer_to_this >
used public external regdecl common SI file t.c line 25 col 14 size
 unit size 
align 32 context 
(reg/v:SI 7 sp [ __SP ])>
$1 = void

for some odd reason we call assemble_undefined_decl on a DECL_HARD_REGISTER
(for some odd reason such decl is in the varpool at all..)

Honza?

This is

register __SP __asm__ ( "%rsp" );

not sure what the underlying issue is.  Works with 4.9.

[Bug middle-end/65595] [5 Regression] Linux kernel build failure: ICE: in as_a, at is-a.h:192

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-27
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jan Hubicka  ---
Mine, will look into it tomorrow.

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener  ---
So how is the compile-time regression now?

[Bug tree-optimization/64715] [5/6 Regression] __builtin_object_size (..., 1) fails to locate subobject

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||4.9.2

--- Comment #23 from Richard Biener  ---
Down-grading to P2.

[Bug middle-end/65595] [5 Regression] Linux kernel build failure: ICE: in as_a, at is-a.h:192

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka  ---
Hi,
the ICE does not reproduce for me, but from backtrace it seems quite clear
that the following fix should work:
Index: cgraph.c
===
--- cgraph.c(revision 221707)
+++ cgraph.c(working copy)
@@ -1516,7 +1516,7 @@ cgraph_update_edges_for_call_stmt_node (
   if (e)
{
  /* Keep calls marked as dead dead.  */
- if (e->callee
+ if (new_call && e->callee
  && DECL_BUILT_IN_CLASS (e->callee->decl) == BUILT_IN_NORMAL
  && DECL_FUNCTION_CODE (e->callee->decl) == BUILT_IN_UNREACHABLE)
{

It is late here, so I will return to it only at morning.  If the patch fixes
the
ICE and passes testing, please just go ahead and commit it.

Honza

[Bug ipa/65478] [5 regression] crafty performance regression

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  ---
Created attachment 35159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35159&action=edit
Patch implementing cloning penalties

(In reply to Martin Jambor from comment #8)
> (In reply to Jan Hubicka from comment #7)
> > Yep, that sounds like resonable thing to try to me.
> > 
> 
> OK, I'll prepare a patch for this part.

This is the patch, it has survived bootstrap and regtest on
x86_64-linux.  I have not measured crafty run-time with it yet.

[Bug ipa/65478] [5 regression] crafty performance regression

[jamborm at gcc dot gnu.org]

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

--- Comment #12 from Martin Jambor  ---
(In reply to Jan Hubicka from comment #9)
> Actually, there is one detail.  Cloning SCC and keeping it a SCC is cool
> thing (as one avoid passing constant parameter across the recursive loop),
> but clonning function from SCC and keeping all calls within the connected
> component to go to the original SCC is not cool.  It would be nice to make
> difference between these.

I understand.  I have actually spent most of Monday trying to do this
at least for the simple cases.  However, I quickly found out simple
hacks did not work and more serious attempts quickly snowballed into
big patches I that I might not finish soon and might not be deemed
reasonable for stage4.  We basically really need to be able to
roll-back all decisions taken when evaluating an SCC.

In the long run, I agree we certainly want to limit or disallow
completely cloning that would leave calls to the original functions of
an SCC.

[Bug sanitizer/65583] [5 Regression][UBSAN] ICE segfault in inline_edge_summary

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar 27 09:33:20 2015
New Revision: 221723

URL: https://gcc.gnu.org/viewcvs?rev=221723&root=gcc&view=rev
Log:
PR sanitizer/65583
* ubsan.c (ubsan_create_edge): New function.
(instrument_bool_enum_load): Call it.
(instrument_nonnull_arg): Likewise.
(instrument_nonnull_return): Likewise.
(instrument_object_size): Likewise.

* g++.dg/ubsan/pr65583.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr65583.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c

[Bug sanitizer/65583] [5 Regression][UBSAN] ICE segfault in inline_edge_summary

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #12 from Marek Polacek  ---
Fixed.

[Bug c++/65525] [5 Regression] ICE: sorry, unimplemented: unexpected AST of kind mem_ref (-std=c++14, ICE: in potential_constant_expression_1, at cp/constexpr.c:4432)

[rogero at howzatt dot demon.co.uk]

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

--- Comment #7 from Roger Orr  ---
Thanks!

[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy

[felix.ospald at gmx dot de]

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

--- Comment #10 from felix.ospald at gmx dot de ---
gcc still compiles, but I think I found the answer here:

http://stackoverflow.com/questions/24219263/openmp-on-a-2-socket-system

"The problem was due to a bug in Linux Kernel kernel 3.11.10-7. The bug may be
due to how the kernel handles invalidating the TLB cache as pointed out by
Hristo Iliev. I guessed that the kernel might be the problem because I read
that there would be some improvements in Linux Kernel 3.15 for NUMA systems so
I figured that the kernel version is important for NUMA systems.

When the OP updated the Linux kernel of his NUMA system to 3.15.0-1 the problem
went away."

As we are running "3.11.10-25-desktop" this is probably the issue.

[Bug fortran/65596] New: [4.9 Regression] NAMELIST bug with f2003: reads too far

[dominiq at lps dot ens.fr]

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

Bug ID: 65596
   Summary: [4.9 Regression] NAMELIST bug with f2003: reads too
far
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: jvdelisle at gcc dot gnu.org

>From https://gcc.gnu.org/ml/fortran/2015-03/msg00138.html, the following test

integer ,parameter :: CL=80
integer ,parameter :: AL=4

character(CL) :: mode
character(CL) :: crats(AL)
character(CL) :: drogs(AL)
integer   :: ierr, k
character(CL) :: msg

namelist / theList / crats, drogs, mode

4 format (a4, "(", i1, ")='", a, "'")

msg = 'none'
mode= 'off'
crats(:) = ''
drogs(:) = ''

read (*, nml=theList, iomsg=msg, iostat=ierr)

print *, "ierr=",ierr
print *, "message='"//trim(msg)//"'"

do k=1,AL
   print 4, "drogs", k, trim(drogs(k))
end do

print *, ""
do k=1,AL
   print 4, "crats", k, trim(crats(k))
end do

end

compiled with -std=f2003 and with the following input

 &theList
   mode  = 'on'
   drogs  = 'Grover',
   'Sprout'
   crats  = 'Flurry',
   'Hairball'
 /

gives the wrong output at run time

 ierr=  -1
 message='End of file'
drog(1)='Grover'
drog(2)='Sprout'
drog(3)='crats  = 'Flurry',
   'Hairball'
 /
'
drog(4)=''

crat(1)=''
crat(2)=''
crat(3)=''
crat(4)=''

Revision r208241 (2014-03-01) is OK, r208311 (2014-03-04) is not (r208302 for
pr60148?). This appears to be fixed on trunk: wrong output at r215860
(2014-10-03) and r216098 (2014-10-10) is OK. I did not find obvious candidate
for the fix.

[Bug ipa/65588] [5 Regression] lto1: internal compiler error: Segmentation fault

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
I will take a look.

[Bug middle-end/65597] New: ICE in build_outer_var_ref, at omp-low.c:1043

[burnus at gcc dot gnu.org]

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

Bug ID: 65597
   Summary: ICE in build_outer_var_ref, at omp-low.c:1043
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

The following Fortran program causes an ICE with -fopenmp; it doesn't with
-fopenmp-simd nor does the equivalent C program ICE:


 !$omp do simd collapse(1)
 ^
internal compiler error: in build_outer_var_ref, at omp-low.c:1206
0xaa0d0c build_outer_var_ref
../../gcc/omp-low.c:1206
0xaae1d1 lower_rec_input_clauses
../../gcc/omp-low.c:3959
0xab1c8a lower_omp_for
../../gcc/omp-low.c:10622


external foo
!$omp do simd collapse(1)
do i = 1, 151, 31
   call foo();
end do
end

[Bug c++/65598] New: Misleading error message for out-of-class definition of explicit conversion operator

[arvo at me dot com]

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

Bug ID: 65598
   Summary: Misleading error message for out-of-class definition
of explicit conversion operator
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arvo at me dot com

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

System report:
OS: GNU/Linux x86_64
Distribution: openSUSE 13.1
Package info:
  Informationen für Paket gcc49-c++:
  --
  Repository: @System
  Name: gcc49-c++
  Version: 4.9.1+r213409-44.1
  Arch: x86_64
  Anbieter: obs://build.opensuse.org/devel:gcc
  Installiert: Ja
  Status: aktuell
  Installierte Größe: 17,3 MiB
  Zusammenfassung: The GNU C++ Compiler
  Beschreibung: 
  This package contains the GNU compiler for C++.


Test program (C++11):

  struct ExplicitTest
  {
  explicit operator bool() const;
  };

  explicit ExplicitTest::operator bool() const
  {
  return true;
  }

The program is ill-formed because explicit is only allowed inside a class
definition, as per §7.1.2/6 Function Specifiers [N3376]. However, the error
message is misleading and seems not to have been updated for C++11, where
explicit conversion operators were introduced:

$ g++-4.9 -c -std=c++11 explicit_operator_bool.cxx
explicit_operator_bool.cxx:6:40: error: only declarations of constructors can
be ‘explicit’
 explicit ExplicitTest::operator bool() const
^

(Also it would probably be better to place the caret underneath "explicit".)

[Bug middle-end/65597] ICE in build_outer_var_ref, at omp-low.c:1043

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed since at least r210749.

[Bug fortran/65596] [4.9 Regression] NAMELIST bug with f2003: reads too far

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Note that while -std=f2003 is needed to reproduce the wrong output with
gfortran 4.9.2/4.9.3, it is not for the range given in comment 0.

[Bug fortran/65596] [4.9 Regression] NAMELIST bug with f2003: reads too far

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.9.3

[Bug c++/65599] New: [c++14] Failing overload resolution when combining return type deduction and explicit R/L-value methods

[anders at sjogren dot info]

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

Bug ID: 65599
   Summary: [c++14] Failing overload resolution when combining
return type deduction and explicit R/L-value methods
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders at sjogren dot info

The following code uses return type deduction (auto) and different methods for
L-value and R-value objects. It seems when combining the two, gcc 4.9.2 has
problems with overload resolution: "call of overloaded 'f()' is ambiguous".

Is this a bug or just another strange C++ corner case? Clang accepts it as
expected.

struct T {
  auto f() & {
return int{0};
  }
  auto f() && {
return string{""};
  }
};

void test_it() {
  //Calling with L-value object. Fails with "call of overloaded 'f()' is
ambiguous").
  T t;
  int s = t.f();

  //Calling with R-value object. Fails with "call of overloaded 'f()' is
ambiguous").
  string i = T{}.f();
}

struct T2 {
  auto f() & -> int {
return 0;
  }
  auto f() && -> string {
return "";
  }
};

void test_it_2() {
  //Calling with L-value object. Works just fine when the return type is
stated!
  T2 t;
  int s = t.f();

  //Calling with R-value object. Works just fine when the return type is
stated!
  string i = T2{}.f();
}

struct T3 {
  auto f() & {
return 0;
  }
  auto f() && -> string {
return "";
  }
};

void test_it_3() {
  //Calling with L-value object. Works fine when the non-selected overload has
a non-deduced return type(!).
  T3 t;
  int s = t.f();

  //Calling with R-value object. Doesn't work even though the selected overload
has a non-deduced return type.
  string i = T3{}.f();
}

The example can be studied using online compilers here:
gcc 4.9.2: http://goo.gl/itZliQ
clang 3.5.1: http://goo.gl/yffVa8

The topic on if its a bug or a c++ quirk was posted on
http://stackoverflow.com/questions/29298029/c-gcc-bug-when-combining-auto-and-r-value-in-methods
, but I also posted it here after that I felt fairly sure it was a bug.

A possibly related bug is:
Bug 64194 - [C++14]  for function template
with auto return

[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy

[felix.ospald at gmx dot de]

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

--- Comment #11 from felix.ospald at gmx dot de ---
I can confirm that the bug still exists for the trunk version (rev 221721) of
gcc.
So as mentioned above it is very likely the kernel bug.

[Bug target/65495] ICE: chkp_make_addressed_object_bounds: Unexpected tree code const_decl with -fcheck-pointer-bounds -mmpx and fortran

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri Mar 27 10:29:04 2015
New Revision: 221725

URL: https://gcc.gnu.org/viewcvs?rev=221725&root=gcc&view=rev
Log:
PR target/65495
* c-family/c.opt (fcheck-pointer-bounds): List supported languages.
(fchkp-check-incomplete-type): Add LTO.
(fchkp-zero-input-bounds-for-main): Likewise.
(fchkp-first-field-has-own-bounds): Likewise.
(fchkp-narrow-bounds): Likewise.
(fchkp-narrow-to-innermost-array): Likewise.
(fchkp-use-static-bounds): Likewise.
(fchkp-use-static-const-bounds): Likewise.
(fchkp-treat-zero-dynamic-size-as-infinite): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/c.opt

[Bug target/65495] ICE: chkp_make_addressed_object_bounds: Unexpected tree code const_decl with -fcheck-pointer-bounds -mmpx and fortran

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ienkovich at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Ilya Enkovich  ---
Fixed

[Bug middle-end/65595] [5 Regression] Linux kernel build failure: ICE: in as_a, at is-a.h:192

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Author: hubicka
Date: Fri Mar 27 10:33:17 2015
New Revision: 221726

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

PR middle-end/65595
* cgraph.c (cgraph_update_edges_for_call_stmt_node): Only
do redirection if the call is not optimized out.

* gcc.c-torture/compile/pr65595.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr65595.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/65595] [5 Regression] Linux kernel build failure: ICE: in as_a, at is-a.h:192

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
Fixed.

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> Well, GOMP_parallel doesn't always create new threads, but still it has some
> synchronization overhead etc.  IMNSHO the testcase should be scaled down for
> the testsuite, IMHO lowering N to 100 would be in order.

Lowering N to 400 or lower introduces this failure:
...
FAIL: libgomp.graphite/force-parallel-6.c scan-tree-dump-times optimized
"loopfn.0" 4
...

When N drops below (MIN_PER_THREAD * N_THREADS) ==  (100 * 4), the loopfn.0 is
still created, but is already unreachable and the call to the function is
removed during the following omp expand.

[Bug c++/65598] Misleading error message for out-of-class definition of explicit conversion operator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
GCC 5 says:

e.cc:6:42: error: ‘explicit’ outside class declaration
   explicit ExplicitTest::operator bool() const
  ^

(The caret position is a well known issue with all error locations, there is
work being done to improve things.)

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
And use M instead of N in the outer two loops and define M to something lower
(100, 50 or similar)?  The test doesn't verify the result anyway.

[Bug c++/60686] message " only declarations of constructors can be ‘explicit’ " now conflicting with C++11

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||arvo at me dot com

--- Comment #5 from Jonathan Wakely  ---
*** Bug 65598 has been marked as a duplicate of this bug. ***

[Bug c++/65598] Misleading error message for out-of-class definition of explicit conversion operator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
Dup

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

[Bug c++/65599] [c++14] Failing overload resolution when combining return type deduction and explicit R/L-value methods

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Dup

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

[Bug c++/60943] [C++1y] Return type deduction interferes with ref-qualifiers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||anders at sjogren dot info

--- Comment #1 from Jonathan Wakely  ---
*** Bug 65599 has been marked as a duplicate of this bug. ***

[Bug fortran/65590] FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=single -O2 -latomic (test for errors)

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2015-03-26, at 5:43 PM, dominiq at lps dot ens.fr wrote:

> This should have been fixed by r221618, see
> https://gcc.gnu.org/ml/fortran/2015-03/msg00124.html.

Fail was with r221591.

Dave
--
John David Anglindave.ang...@bell.net

[Bug target/65593] [5 Regression] internal compiler error: in extract_insn, at recog.c:2343

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Looks like a bug in legitimize_pic_address.  Working on a fix.

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> And use M instead of N in the outer two loops and define M to something
> lower (100, 50 or similar)? 

Yep, that works:
...
index 5071630..e9e4b56 100644
--- a/libgomp/testsuite/libgomp.graphite/force-parallel-6.c
+++ b/libgomp/testsuite/libgomp.graphite/force-parallel-6.c
@@ -1,4 +1,5 @@
 #define N 500
+#define M 50

 int X[2*N], Y[2*N], B[2*N];
 int A[2*N][2*N], C[2*N][2*N];
@@ -7,10 +8,10 @@ int foo(void)
 {
   int i, j, k;

-  for (i = 0; i < N; i++)
+  for (i = 0; i < M; i++)
 {
   X[i] = Y[i] + 10;
-  for (j = 0; j < N; j++)
+  for (j = 0; j < M; j++)
{
  B[j] = A[j][N];
  for (k = 0; k < N; k++)
...

The only tricky bit is that N is used as array index twice, but I don't think
those need updating.

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> The test doesn't verify the result anyway.

I've written some initialization and verification code:
...
index e9e4b56..cbc5735 100644
--- a/libgomp/testsuite/libgomp.graphite/force-parallel-6.c
+++ b/libgomp/testsuite/libgomp.graphite/force-parallel-6.c
@@ -1,10 +1,31 @@
+void abort (void);
+
 #define N 500
 #define M 50

 int X[2*N], Y[2*N], B[2*N];
 int A[2*N][2*N], C[2*N][2*N];

-int foo(void)
+static void __attribute__((noinline,noclone))
+init (void)
+{
+  volatile int i, j;
+
+  for (i = 0; i < 2 * N; ++i)
+{
+  B[i] = 1;
+  X[i] = 1;
+  Y[i] = 1;
+  for (j = 0; j < 2 * N; ++j)
+   {
+ A[i][j] = 1;
+ C[i][j] = 1;
+   }
+}
+}
+
+static void __attribute__((noinline,noclone))
+foo (void)
 {
   int i, j, k;

@@ -21,13 +42,38 @@ int foo(void)
  Y[i+j] = A[j+1][N];
}
 }
+}

-  return A[1][5]*B[6];
+static void __attribute__((noinline,noclone))
+check (void)
+{
+  volatile int i, j;
+
+  for (i = 0; i < 2 * N; ++i)
+{
+  int expect_x = i < M ? 11 : 1;
+
+  if (B[i] != 1
+ || X[i] != expect_x
+ || Y[i] != 1)
+   abort ();
+
+  for (j = 0; j < 2 * N; ++j)
+   {
+ int expect_a = (0 < i && i <= M && j < N) ? 2 : 1;
+
+ if (A[i][j] != expect_a
+ || C[i][j] != 1)
+   abort ();
+   }
+}
 }

 int main(void)
 {
-  foo();
+  init ();
+  foo ();
+  check ();

   return 0;
 }
...

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
LGTM, thanks.

[Bug ipa/65600] New: [5 Regression] bost testsuite failure: ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Bug ID: 65600
   Summary: [5 Regression] bost testsuite failure: ICE:
Segmentation fault
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

Running the boost testsuite on ppc64le shows:

trippels@gcc2-power8 tools % cat weak_ptr_move_test.ii
class A {
public:
  virtual void m_fn1() {}
  int weak_release___trans_tmp_1;
  void m_fn2() {
__asm__("0\n\tlwarx   %2\n\taddi   1\n\tstwcx.   %2\n\tbne 0b\n\tisync");
if (weak_release___trans_tmp_1)
  m_fn1();
  }
};
class weak_count {
  A *pi_;

public:
  weak_count() : pi_() {}
  ~weak_count() {
if (pi_)
  pi_->m_fn2();
  }
};
class B {
  weak_count pn;
};
int
main() { B a; }

trippels@gcc2-power8 tools % g++ -O2 -std=c++11 weak_ptr_move_test.ii
weak_ptr_move_test.ii:25:15: internal compiler error: Segmentation fault
 main() { B a; }
   ^
0x10a1f773 crash_signal
../../gcc/gcc/toplev.c:383
0x1053958c symtab_node::semantically_equivalent_p(symtab_node*)
../../gcc/gcc/symtab.c:1631
0x10547177 cgraph_edge::resolve_speculation(tree_node*)
../../gcc/gcc/cgraph.c:1169
0x107e7653 redirect_to_unreachable
../../gcc/gcc/ipa-inline-analysis.c:771
0x107e7653 edge_set_predicate
../../gcc/gcc/ipa-inline-analysis.c:797
0x107ec4b3 remap_edge_summaries
../../gcc/gcc/ipa-inline-analysis.c:3506
0x107eefef inline_merge_summary(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3653
0x11079ed7 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
../../gcc/gcc/ipa-inline-transform.c:357
0x1107085b inline_small_functions
../../gcc/gcc/ipa-inline.c:1949
0x1107085b ipa_inline
../../gcc/gcc/ipa-inline.c:2352
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Mar 27 12:10:16 2015
New Revision: 221728

URL: https://gcc.gnu.org/viewcvs?rev=221728&root=gcc&view=rev
Log:
Add verification to libgomp.graphite/force-parallel-6.c

2015-03-27  Tom de Vries  

PR testsuite/65594
* testsuite/libgomp.graphite/force-parallel-6.c (abort): Declare.
(init, check): New function.
(foo): Change return type to void.
(main): Call init and check.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.graphite/force-parallel-6.c

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Mar 27 12:10:07 2015
New Revision: 221727

URL: https://gcc.gnu.org/viewcvs?rev=221727&root=gcc&view=rev
Log:
Scale down libgomp.graphite/force-parallel-6.c

2015-03-27  Tom de Vries  

PR testsuite/65594
* testsuite/libgomp.graphite/force-parallel-6.c (M): Define.
(foo): Use M for non-inner loops to scale down test-case.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.graphite/force-parallel-6.c

[Bug testsuite/65594] libgomp.graphite/force-parallel-6.c timeout

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from vries at gcc dot gnu.org ---
Patches committed, marking resolved fixed.

[Bug ipa/65600] [5 Regression] bost testsuite failure: ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Started with r221718.

[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-03-27
 Ever confirmed|0   |1

--- Comment #12 from Jakub Jelinek  ---
Waiting until you retry with a fixed kernel.

[Bug libstdc++/65499] Missing "using namespace literals::chrono_literals" in std::chrono

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Mar 27 12:45:10 2015
New Revision: 221730

URL: https://gcc.gnu.org/viewcvs?rev=221730&root=gcc&view=rev
Log:
PR libstdc++/65499
* include/std/chrono: Add using-directive for literals to std::chrono.
* testsuite/20_util/duration/literals/65499.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/duration/literals/65499.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/chrono

[Bug libstdc++/65499] Missing "using namespace literals::chrono_literals" in std::chrono

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Small enough and safe enough for 5.0

[Bug c++/65598] Fix column location for 'explicit'

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2015-03-27
 CC||manu at gcc dot gnu.org
 Resolution|DUPLICATE   |---
Summary|Misleading error message|Fix column location for
   |for out-of-class definition |'explicit'
   |of explicit conversion  |
   |operator|
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #1)
> GCC 5 says:
> 
> e.cc:6:42: error: ‘explicit’ outside class declaration
>explicit ExplicitTest::operator bool() const
>   ^
> 
> (The caret position is a well known issue with all error locations, there is
> work being done to improve things.)

I don't think we have a bug open for 'explicit', so this one could be it. It is
probably an EasyHack ideal for a new contributor. Please consider submitting a
patch:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

Small patches don't need any copyright assignment!

[Bug ipa/65600] [5 Regression] bost testsuite failure: ICE: Segmentation fault

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
Oops, really hope this is last one  of this can of worms :(
The problem here is that resolve_speculation assumes the cgraph node exists. I
am testing the following:

Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c(revision 221725)
+++ ipa-inline-analysis.c(working copy)
@@ -766,15 +766,15 @@ static struct cgraph_edge *
 redirect_to_unreachable (struct cgraph_edge *e)
 {
   struct cgraph_node *callee = !e->inline_failed ? e->callee : NULL;
+  struct cgraph_node *target = cgraph_node::get_create
+  (builtin_decl_implicit (BUILT_IN_UNREACHABLE));

   if (e->speculative)
-e = e->resolve_speculation (builtin_decl_implicit (BUILT_IN_UNREACHABLE));
+e = e->resolve_speculation (target->decl);
   else if (!e->callee)
-e->make_direct (cgraph_node::get_create
-  (builtin_decl_implicit (BUILT_IN_UNREACHABLE)));
+e->make_direct (target);
   else
-e->redirect_callee (cgraph_node::get_create
-(builtin_decl_implicit (BUILT_IN_UNREACHABLE)));
+e->redirect_callee (target);
   struct inline_edge_summary *es = inline_edge_summary (e);
   e->inline_failed = CIF_UNREACHABLE;
   e->frequency = 0;

[Bug web/65601] New: add bugzilla keyword "easyhack"

[manu at gcc dot gnu.org]

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

Bug ID: 65601
   Summary: add bugzilla keyword "easyhack"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org
CC: LpSolit at netscape dot net

I have been maintaining a list of bugs that should be easy to fix for new
contributors in the wiki: https://gcc.gnu.org/wiki/EasyHacks but it takes too
much time to maintain the list by hand.

It would be great if we had a new keyword "easyhack", such that PRs can be
marked with it and a list of bugs automatically generated.

Bonus points for some kind of moinmoin script/extension that automatically
fetches the list and populates a table in the wiki: See
https://wiki.documentfoundation.org/Development/Easy_Hacks/lists/by_Topic

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
A working patch has been submitted at
https://gcc.gnu.org/ml/fortran/2015-03/msg00132.html.

[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy

[felix.ospald at gmx dot de]

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

felix.ospald at gmx dot de changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from felix.ospald at gmx dot de ---
We updated to the 3.19 kernel.
http://download.opensuse.org/repositories/Kernel:/stable/standard/x86_64/kernel-desktop-3.19.2-3.1.gd8856ce.x86_64.rpm
 

Since then the problem is gone.

[Bug target/65602] New: gcc.target/i386/mpx tests FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 65602
   Summary: gcc.target/i386/mpx tests FAIL
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: ienkovich at gcc dot gnu.org
  Host: i386-pc-solaris2.1[01]
Target: i386-pc-solaris2.1[01]
 Build: i386-pc-solaris2.1[01]

Many of the new gcc.target/i386/mpx tests FAIL on Solaris/x86 with gas, causing
enormous amounts of testsuite noise.  The failures fall into two categories:

FAIL: gcc.target/i386/mpx/alloca-1-lbv.c   -O0  (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/mpx/alloca-1-lbv.c:19:21:
warning: implicit declaration of function 'alloca'
[-Wimplicit-function-declaration]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/mpx/alloca-1-lbv.c:19:21:
warning: incompatible implicit declaration of built-in function 'alloca'

It seems the tests should simply use __builtin_alloca instead.

FAIL: gcc.target/i386/mpx/calloc-1-lbv.c   -O0  (test for excess errors)
Excess errors:
Undefined   first referenced
 symbol in file
__mpx_wrapper_calloc/var/tmp//ccEYaOnw.o
ld: fatal: symbol referencing errors

WARNING: gcc.target/i386/mpx/calloc-1-lbv.c   -O0  compilation failed to
produce executable

All link tests will fail on all non-Linux targets since only those provide the
MPX runtime libraries. The check_effective_target_mpx test in
gcc.target/i386/mpx/mpx.exp is incomplete, it seems.  IMO the test should be
fixed, rather
than hardcoding Linux/x86 here, which will start to become wrong once non-Linux
targets start to support MPX.

  Rainer

[Bug target/65602] gcc.target/i386/mpx tests FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #14 from Jakub Jelinek  ---
As it isn't a gcc bug, closing as fixed.

[Bug target/65602] gcc.target/i386/mpx tests FAIL

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
(In reply to Rainer Orth from comment #0)
> All link tests will fail on all non-Linux targets since only those provide
> the
> MPX runtime libraries. The check_effective_target_mpx test in
> gcc.target/i386/mpx/mpx.exp is incomplete, it seems.  IMO the test should be
> fixed, rather
> than hardcoding Linux/x86 here, which will start to become wrong once
> non-Linux
> targets start to support MPX.
> 
>   Rainer

check_effective_target_mpx defined in lib/mpx-dg.exp is a link test. How comes
it may pass with no libraries available?

[Bug target/65593] [5 Regression] internal compiler error: in extract_insn, at recog.c:2343

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/52763] Warning if compare between enum and non-enum type

[g...@mundle-online.net]

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

g...@mundle-online.net changed:

   What|Removed |Added

 CC||g...@mundle-online.net

--- Comment #6 from g...@mundle-online.net ---
In the documentation of GCC 4.6.3
https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Warning-Options.html#index-Wextra-249

as well as in the current one
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Warning-Options.html#index-Wextra-285

it is written, that -Wextra enables this kind of warnings:
"The option -Wextra also prints warning messages for the following cases:
...
(C++ only) An enumerator and a non-enumerator both appear in a conditional
expression. "

Instead of a discussion, if this warning makes sense or not, it is definitely a
bug, either in gcc or in the documentation.

For me it would be nice to get this kind of warnings, to port code, which uses
hash defines and integer values, to the usage of enums. 

The warning is also missing in 4.8.2 (Ubuntu 4.8.2-19ubuntu1).

[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).

[howarth at bromo dot med.uc.edu]

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

--- Comment #17 from howarth at bromo dot med.uc.edu ---
Bug 65550 may be a duplicate of this one.

[Bug target/65052] ICE in c6x-uclinux target when building libgcc

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bernds at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Bernd Schmidt  ---
Should be fixed now.

[Bug pch/65550] [5 Regression] ICE (segfault) with pch

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at bromo dot med.uc.edu

--- Comment #2 from howarth at bromo dot med.uc.edu ---
This bug may be a duplicate of Bug 61250.

[Bug lto/65603] [5 Regression] lto1: internal compiler error: in as_a, at is-a.h:192

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
This is 176.gcc in SPEC CPU 2000.

[Bug lto/65603] New: [5 Regression] lto1: internal compiler error: in as_a, at is-a.h:192

[hjl.tools at gmail dot com]

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

Bug ID: 65603
   Summary: [5 Regression] lto1: internal compiler error: in as_a,
at is-a.h:192
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

On Linux/x86-64, r221721 gave

gcc -c -o obstack.o   -DSPEC_CPU2000_LP64 -Dalloca=_alloca-O3
-funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin 
obstack.c
gcc -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin -DSPEC_CPU2000_LP64 c-parse.o c-lang.o c-lex.o c-pragma.o
c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-iterate.o toplev.o
version.o tree.o print-tree.o stor-layout.o fold-const.o function.o stmt.o
expr.o calls.o expmed.o explow.o optabs.o varasm.o rtl.o print-rtl.o rtlanal.o
emit-rtl.o real.o dbxout.o sdbout.o dwarfout.o xcoffout.o integrate.o jump.o
cse.o loop.o unroll.o flow.o stupid.o combine.o regclass.o local-alloc.o
global.o reload.o reload1.o caller-save.o insn-peep.o reorg.o sched.o final.o
recog.o reg-stack.o insn-opinit.o insn-recog.o insn-extract.o insn-output.o
insn-emit.o insn-attrtab.o m88k.o getpwd.o convert.o bc-emit.o bc-optab.o
obstack.o   -lm  -o cc1
In function 'set_float_handler.constprop':
lto1: internal compiler error: in as_a, at is-a.h:192
0x6856d8 gcall* as_a(gimple_statement_base*)
../../src-trunk/gcc/is-a.h:192
0x6856d8 cgraph_update_edges_for_call_stmt_node
../../src-trunk/gcc/cgraph.c:1524
0x685a19 cgraph_update_edges_for_call_stmt(gimple_statement_base*, tree_node*,
gimple_statement_base*)
../../src-trunk/gcc/cgraph.c:1588
0xa96570 fold_marked_statements
../../src-trunk/gcc/tree-inline.c:4843
0xaa39c4 tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*)
../../src-trunk/gcc/tree-inline.c:5813
0x692c13 cgraph_materialize_clone
../../src-trunk/gcc/cgraphclones.c:1056
0x692c13 symbol_table::materialize_all_clones()
../../src-trunk/gcc/cgraphclones.c:1153
0x68d969 symbol_table::compile()
../../src-trunk/gcc/cgraphunit.c:2326
0x602f84 lto_main()
../../src-trunk/gcc/lto/lto.c:3496
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccBkg1Up.ltrans3.ltrans.o] Error 1

[Bug target/65604] New: MIPS -fno-delayed-branch generates incorrect code with -mcheck-zero-division

[azonenberg at drawersteak dot com]

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

Bug ID: 65604
   Summary: MIPS -fno-delayed-branch generates incorrect code with
-mcheck-zero-division
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: azonenberg at drawersteak dot com

When compiling code that performs integer division on MIPS with
-fno-delayed-branch and -mcheck-zero-division enabled, the generated code still
uses delay slots.

Example disassembly:

42e8:  1442  bnezv0,42f4 
42ec:  0062001a  div zero,v1,v0
42f0:  0007000d  break   0x7
42f4:  1810  mfhiv1

Expected result: Code generated with -fno-delayed-branch will run correctly on
a MIPS-like processor that does not have delay slots

Actual result: The divide is never executed on processors without delay slots
since the branch jumps.

I first noticed the issue on mips-elf-gcc 4.9.2 and have not yet tested to see
what other version(s) it is present in.

[Bug lto/65603] [5 Regression] lto1: internal compiler error: in as_a, at is-a.h:192

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Perhaps dup of PR65595 ?

[Bug target/65602] gcc.target/i386/mpx tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Ilya Enkovich  ---
> (In reply to Rainer Orth from comment #0)
>> All link tests will fail on all non-Linux targets since only those provide
>> the
>> MPX runtime libraries. The check_effective_target_mpx test in
>> gcc.target/i386/mpx/mpx.exp is incomplete, it seems.  IMO the test should be
>> fixed, rather
>> than hardcoding Linux/x86 here, which will start to become wrong once
>> non-Linux
>> targets start to support MPX.
>> 
>>   Rainer
>
> check_effective_target_mpx defined in lib/mpx-dg.exp is a link test. How comes
> it may pass with no libraries available?

I suppose because it only links with -lmpx on Linux/x86: this only
happens in gcc/config/i386/linux-common.h, but not for other x86
targets.

Rainer

[Bug lto/65603] [5 Regression] lto1: internal compiler error: in as_a, at is-a.h:192

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #2)
> Perhaps dup of PR65595 ?

Yes.

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

[Bug middle-end/65595] [5 Regression] Linux kernel build failure: ICE: in as_a, at is-a.h:192

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #6 from Markus Trippelsdorf  ---
*** Bug 65603 has been marked as a duplicate of this bug. ***

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Lowering to P2 on Honza's request.

[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #14 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01441.html

[Bug target/65602] gcc.target/i386/mpx tests FAIL

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
Created attachment 35162
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35162&action=edit
patch to fix mpx target check and alloca usage

(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> I suppose because it only links with -lmpx on Linux/x86: this only
> happens in gcc/config/i386/linux-common.h, but not for other x86
> targets.
> 
>   Rainer

I see.  Attached is a patch which checks wrappers are linked.  It also fixes
alloca tests.  Unfortunately I can only check it doesn't regress on Linux. 
Could you please check it helps on Solaris/x86?

[Bug c++/52763] Warning if compare between enum and non-enum type

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to eldnumh from comment #6)
> In the documentation of GCC 4.6.3
> https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Warning-Options.html#index-
> Wextra-249
> 
> as well as in the current one
> https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Warning-Options.html#index-
> Wextra-285
> 
> it is written, that -Wextra enables this kind of warnings:
> "The option -Wextra also prints warning messages for the following cases:
> ...
> (C++ only) An enumerator and a non-enumerator both appear in a
> conditional expression. "

That is for cases such as:

enum a { A = -1 };
int foo(int cond, unsigned int value)
{
 return cond ? A : value;
}

which are different.

[Bug ipa/65588] [5 Regression] lto1: internal compiler error: Segmentation fault

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
The reduced testcase does not reproduce for me.  The original source does.  We
do insert undefined register variables into symbol table (not sure how much
sense it makes, but lets not change it now).

The problem here seems to be that we partition the program in a way that there
are two ltrans units using the hard register and we attempt to promote it as
hidden and partition into one of units.

I am testing fix.

[Bug target/65407] Extra mask register move in gcc.target/i386/avx512f-kandnw-1.c

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Mar 27 14:47:24 2015
New Revision: 221734

URL: https://gcc.gnu.org/viewcvs?rev=221734&root=gcc&view=rev
Log:
2015-03-27  Vladimir Makarov  

PR target/65407
* ira-costs.c (record_reg_classes): Process all constraint string
containing 0-9.

2015-03-27  Vladimir Makarov  

PR target/65407
* gcc.target/i386/avx512f-kandnw-1.c: Add scanning kmovw.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-costs.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx512f-kandnw-1.c

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

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

--- Comment #3 from Andrew Sutton  ---
Created attachment 35163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35163&action=edit
Patch applied in r221733

[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type

[andrew.n.sutton at gmail dot com]

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

--- Comment #4 from Andrew Sutton  ---
Apparently I do not understand declarators. The attached patch searches through
the declarator structure to filter out declarator structures to which a
requires-clause cannot be attached.

I updated the pr665575.C test to include more examples (positive and negative),
but that's not reflected in the attached patch. I haven't been able to test as
thoroughly as I'd like because I'm at the airport, but this seems like the
right thing to do.

[Bug ipa/65588] [5 Regression] lto1: internal compiler error: Segmentation fault

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
Hi,
this patch fixes the partitioner and also avoids assemble_undefined_decl to be
called
on hard registers and value exprs.  I am not sure how the reduced testcase
could work,
since I think the bug needs partitioning to reproduce. So I would welcome if
someone
can reproduce the reduced one could test that it is indeed fixed.

Index: varpool.c
===
--- varpool.c(revision 221725)
+++ varpool.c(working copy)
@@ -737,7 +737,9 @@ symbol_table::output_variables (void)
   timevar_push (TV_VAROUT);

   FOR_EACH_VARIABLE (node)
-if (!node->definition)
+if (!node->definition
+&& !DECL_HAS_VALUE_EXPR_P (node->decl)
+ && !DECL_HARD_REGISTER (node->decl))
   assemble_undefined_decl (node->decl);
   FOR_EACH_DEFINED_VARIABLE (node)
 {
Index: symtab.c
===
--- symtab.c(revision 221725)
+++ symtab.c(working copy)
@@ -1684,6 +1689,8 @@ symtab_node::get_partitioning_class (voi
  objects that can not be duplicated across partitions.  */
   if (DECL_IN_CONSTANT_POOL (decl))
 return SYMBOL_DUPLICATE;
+  if (DECL_HARD_REGISTER (decl))
+return SYMBOL_DUPLICATE;
   gcc_checking_assert (vnode->definition);
 }
   /* Functions that are cloned may stay in callgraph even if they are unused.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #37 from Manuel López-Ibáñez  ---
(In reply to do...@seketeli.org from comment #9)
> "manu at gcc dot gnu.org"  a écrit:
> 
> > So either one keeps track of all source locations of all "interesting"
> > characters within strings, which sounds infeasible. Or one needs to
> > re-preprocess the format string, creating new locations on-the-fly. Dodji, 
> > is
> > this possible?
> 
> With the current infrastructure, I fear we cannot re-process the format
> string *after* the initial pre-processing phase is done, to create new
> locations that we'd a in the line maps.

I'm thinking whether we cannot simply add a new RENAME map on the fly just
before emitting an error. We could even replace the source_location of the
string with this new map starting location.

[Bug target/65052] ICE in c6x-uclinux target when building libgcc

[dhowells at redhat dot com]

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

--- Comment #6 from dhowells at redhat dot com  ---
Fixed how?  Is Nick's patch good?

[Bug web/65601] add bugzilla keyword "easyhack"

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
https://gcc.gnu.org/bugzilla/editkeywords.cgi?action=add

[Bug ipa/65600] [5 Regression] bost testsuite failure: ICE: Segmentation fault

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Fri Mar 27 15:13:54 2015
New Revision: 221735

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

PR ipa/65600
* cgraph.c (cgraph_update_edges_for_call_stmt_node): Fix the case
of optimized out indirect call.
(redirect_to_unreachable): Always build symbol table node for
BUILT_IN_UNREACHABLE
* g++.dg/torture/pr65600.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr65600.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/ipa-inline-analysis.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/65600] [5 Regression] bost testsuite failure: ICE: Segmentation fault

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
Fixed.

[Bug target/65560] [5 Regression] pr24683.c:11:1: internal compiler error: in extract_insn, at recog.c:2343

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Uroš Bizjak  ---
Duplicate of PR65593.

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

[Bug target/65593] [5 Regression] internal compiler error: in extract_insn, at recog.c:2343

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||rai...@emrich-ebersheim.de

--- Comment #5 from Uroš Bizjak  ---
*** Bug 65560 has been marked as a duplicate of this bug. ***

[Bug target/65531] ICE: symtab_node::verify failed: Two symbols with same comdat_group are not linked by the same_comdat_group list. with -fcheck-pointer-bounds -mmpx

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Author: hubicka
Date: Fri Mar 27 15:19:35 2015
New Revision: 221736

URL: https://gcc.gnu.org/viewcvs?rev=221736&root=gcc&view=rev
Log:
PR target/65531
* symtab.c (symtab_node::verify_symtab_nodes): Fix verification of
comdat groups.

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

[Bug lto/65536] LTO line number information garbled

[manu at gcc dot gnu.org]

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

--- Comment #49 from Manuel López-Ibáñez  ---
(In reply to Jan Hubicka from comment #46)
> Manuel,
> I will hopefully commit the cache patch today or tomorrow morning. It does
> not solve full issue. What we have is
> 1) we still drop columns for firefox&chromium pretty early

I think the current limits are too conservative. In particular, the limit in
linemap_position_for_column does not make sense to me. I would suggest trying
something like:

Index: line-map.c
===
--- line-map.c  (revision 221728)
+++ line-map.c  (working copy)
@@ -24,10 +24,22 @@ along with this program; see the file CO
 #include "line-map.h"
 #include "cpplib.h"
 #include "internal.h"
 #include "hashtab.h"

+/* Do not track column numbers higher than this one.  As a result, the
+   range of column_bits is [7, 18] (or 0 if column numbers are
+   disabled).  */
+#define LINE_MAP_MAX_COLUMN_NUMBER (1U << 17)
+
+/* Do not track column numbers if locations get higher than this.  */
+#define LINE_MAP_MAX_LOCATION_WITH_COLS 0x7000
+
+/* Highest possible source location encoded within an ordinary or
+   macro map.  */
+#define LINE_MAP_MAX_SOURCE_LOCATION 0x7FF0
+
 static void trace_include (const struct line_maps *, const struct line_map *);
 static const struct line_map * linemap_ordinary_map_lookup (struct line_maps
*,
source_location);
 static const struct line_map* linemap_macro_map_lookup (struct line_maps *,
source_location);
@@ -528,26 +543,28 @@ linemap_line_start (struct line_maps *se
   || (line_delta > 10
  && line_delta * ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) > 1000)
   || (max_column_hint >= (1U << ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map)))
   || (max_column_hint <= 80
  && ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) >= 10)
-  || (highest > 0x6000
- && (set->max_column_hint || highest > 0x7000)))
+  || (highest > LINE_MAP_MAX_LOCATION_WITH_COLS
+ && (set->max_column_hint || highest >=
LINE_MAP_MAX_SOURCE_LOCATION)))
 add_map = true;
   else
 max_column_hint = set->max_column_hint;
   if (add_map)
 {
   int column_bits;
-  if (max_column_hint > 10 || highest > 0x6000)
+  if (max_column_hint > LINE_MAP_MAX_COLUMN_NUMBER
+ || highest > LINE_MAP_MAX_LOCATION_WITH_COLS)
{
  /* If the column number is ridiculous or we've allocated a huge
 number of source_locations, give up on column numbers. */
  max_column_hint = 0;
- if (highest > 0x7000)
-   return 0;
  column_bits = 0;
+
+ if (set->highest_location >= LINEMAPS_MACRO_LOWEST_LOCATION (set) -
1)
+   return 0;
}
   else
{
  column_bits = 7;
  while (max_column_hint >= (1U << column_bits))
@@ -598,19 +628,25 @@ linemap_position_for_column (struct line
   linemap_assert
 (!linemap_macro_expansion_map_p (LINEMAPS_LAST_ORDINARY_MAP (set)));

   if (to_column >= set->max_column_hint)
 {
-  if (r >= 0xC00 || to_column > 10)
+  if (r > LINE_MAP_MAX_LOCATION_WITH_COLS
+ || to_column > LINE_MAP_MAX_COLUMN_NUMBER)
{
  /* Running low on source_locations - disable column numbers.  */
+ if (r >= LINEMAPS_MACRO_LOWEST_LOCATION (set) - 1)
+   return 0;
  return r;
}
   else
{
  struct line_map *map = LINEMAPS_LAST_ORDINARY_MAP (set);
  r = linemap_line_start (set, SOURCE_LINE (map, r), to_column + 50);
+ /* We just got to overflow; disable column numbers.  */
+ if (to_column >= set->max_column_hint)
+   return r;
}
 }
   r = r + to_column;
   if (r >= set->highest_location)
 set->highest_location = r;


Unfortunately, I cannot get a pristine lto-boostrap to succeed, it fails with:

/home/manuel/test1/221728/build/./prev-gcc/xg++
-B/home/manuel/test1/221728/build/./prev-gcc/
-B/home/manuel/test1/./221728/install/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/manuel/test1/221728/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/manuel/test1/221728/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/manuel/test1/221728/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/home/manuel/test1/221728/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/home/manuel/test1/pristine/libstdc++-v3/libsupc++
-L/home/manuel/test1/221728/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/manuel/test1/221728/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -flto=jobserver -frandom-seed=1 -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qu

[Bug c++/65591] G++ should use default constructor for {}-init when possible

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED
 Depends on||65503

--- Comment #2 from Jason Merrill  ---
Actually, the standard (8.5.1/8.5.4) says we need to do aggregate
initialization here, so this is either a language issue or a duplicate of bug
65503.

[Bug web/65601] add bugzilla keyword "easyhack"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Andreas Schwab from comment #1)
> https://gcc.gnu.org/bugzilla/editkeywords.cgi?action=add

Ops, I missed that completely. Thanks!

[Bug tree-optimization/65511] transform_to_exit_first_loop looses edge probabilities

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
Created attachment 35164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35164&action=edit
patch with test-case, currently testing

[Bug libfortran/65605] New: [4.9 Regression] Namelist mishandles delim

[jvdelisle at gcc dot gnu.org]

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

Bug ID: 65605
   Summary: [4.9 Regression] Namelist mishandles delim
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: jvdelisle at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org

Reported to me off list.  This is related to pr60148.  It is fixed on trunk by
the fix to pr63460 which did get backported to 4.9.  The fix to pr60148
probably needs to be backported to 4.9 as well.

Input:

 &theList
   mode  = 'on'
   dogs  = 'Rover',
   'Spot'
   cats  = 'Fluffy',
   'Hairball'
 /

Case:

integer ,parameter :: CL=80
integer ,parameter :: AL=4

character(CL) :: mode
character(CL) :: cats(AL)
character(CL) :: dogs(AL)
integer   :: ierr, k
character(CL) :: msg

namelist / theList / cats, dogs, mode

4 format (a4, "(", i1, ")='", a, "'")

msg = 'none'
mode= 'off'
cats(:) = ''
dogs(:) = ''

read (*, nml=theList, iomsg=msg, iostat=ierr)

print *, "ierr=",ierr
print *, "message='"//trim(msg)//"'"

do k=1,AL
   print 4, "dogs", k, trim(dogs(k))
end do

print *, ""
do k=1,AL
   print 4, "cats", k, trim(cats(k))
end do

end