[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
Looking at the backtrace, all functions are 0x707
until the __gcov_merge_add which is 0x77fe so apparently coming from a
different DSO. This seems to be because the pointer come from gcov_info
desciptor that bids to different hidden instance. How this is supposed to work?

#2  0x77fe1d1e in __gcov_read_counter () at
../../../libgcc/../gcc/gcov-io.c:555
#3  0x77fe144d in gcov_get_counter () at ../../../libgcc/libgcov.h:316
#4  __gcov_merge_add (counters=0x77fe66f8
<__gcov0._Z30mozalloc_set_oom_abort_handlerPFvmE>, n_counters=)
at ../../../libgcc/libgcov-merge.c:56
#5  0x70758f28 in merge_one_data (crc32=3347144653,
eof_pos_p=, summary_pos_p=,
this_prg=0x7fff8d60, prg_p=0x7fffa530,
gi_ptr=0x77fe6340, filename=0x76f41920
"/aux/hubicka/firefox6-50-lto-fdo3/memory/mozalloc/Unified_cpp_memory_mozalloc0.gcda")
at ../../../libgcc/libgcov-driver.c:472
#6  dump_one_gcov (all_prg=, this_prg=0x7fff8d60,
crc32=3347144653, run_counted=0, gf=, gi_ptr=0x77fe6340)
at ../../../libgcc/libgcov-driver.c:787
#7  gcov_do_dump (list=, run_counted=0) at
../../../libgcc/libgcov-driver.c:846
#8  0x70759242 in __gcov_dump_one (root=root@entry=0x77fe7760
<__gcov_root>) at ../../../libgcc/libgcov-driver.c:858
#9  0x70714fe8 in __gcov_dump_int () at
../../../libgcc/libgcov-interface.c:164
#

[Bug c++/64870] value not set via reference

[conradsand.arma at gmail dot com]

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

--- Comment #6 from Conrad  ---
(In reply to Andrew Pinski from comment #5)
> No, that is not how C++ defines it.  As mentioned before C++ does not define
> the order of the execution of the operands.

I agree this is not how C++ defines it. At the same time, changing the order
from left-to-right "just because we can" is not a good strategy either,
especially for iostreams.

> There is no wtf moments.  This is not Java which has well defined behavior
> :).

Ha :-)  I'd still like to see some concrete benchmarks to support re-ordering. 
Otherwise it can be argued that the re-ordering is actually counter productive,
given its unintuitive behaviour.

Given a choice between gcc and clang, I'd pick clang because it's simply better
behaved.  This is not to dismiss the great effort put into gcc, but
user-friendliness is important.

[Bug middle-end/64592] [5 regression] tramp3d EH unwind tables are 50% bigger with mainline compared to GCC 4.9

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Jakub Jelinek  ---
Must be some Debian specific bug.  I've tried Fedora binutils 2.22 as well as
some earlier ones and cfi advance configury test on the trunk passes just fine.
In any case, I think the problem is analyzed and is caused by buggy assembler.

[Bug c++/64870] value not set via reference

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Conrad from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > No, that is not how C++ defines it.  As mentioned before C++ does not define
> > the order of the execution of the operands.
> 
> I agree this is not how C++ defines it. At the same time, changing the order
> from left-to-right "just because we can" is not a good strategy either,
> especially for iostreams.

There is no re-order.  One of the reasons why the order is different is due to
the different ABIs pass arguments.  Some pass them low on the stack to higher,
others opposite way around.  There are two ABIs on x86 that have the opposite
order.

> 
> > There is no wtf moments.  This is not Java which has well defined behavior
> > :).
> 
> Ha :-)  I'd still like to see some concrete benchmarks to support
> re-ordering.  Otherwise it can be argued that the re-ordering is actually
> counter productive, given its unintuitive behaviour.
> 
> Given a choice between gcc and clang, I'd pick clang because it's simply
> better behaved.  This is not to dismiss the great effort put into gcc, but
> user-friendliness is important.

User-friendliness is important but this is not about user-friendliness now.  It
is more about understanding the language that you are writing in.  we have
-Wsequence-point and that normally catches this but with arguments that take
references (or address of variables), it is hard to tell if that function will
change the value or not.

Mis-understanding the language is a common issue and that is why there is even
an FAQ about this exact issue (it has been part of GCC's documentation for at
least 10 years now even).  I also wonder how old
http://c-faq.com/expr/seqpoints.html is too :).

Or better yet:
http://www.stroustrup.com/bs_faq2.html#evaluation-order

[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks

[dodji at seketeli dot org]

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

--- Comment #6 from dodji at seketeli dot org  ---
"mpolacek at gcc dot gnu.org"  a écrit:

> I'm going to prepare the porting_to bit

Thank you for doing that!

> then I think we should close this bug.

FWIW, I agree.

[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Fri, 30 Jan 2015, brooks at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
> 
> --- Comment #13 from Brooks Moses  ---
> FWIW, if you haven't done the 4.9 backport yet, this is what I ended up with. 
> I'm not sure it's optimal, but it seems to work.

Looks optimal to me - so if you bootstrapped and tested this it is ok
to apply to the branch (with the testcase also backported of course).

> Index: gcc/tree-data-ref.c
> ===
> --- gcc/tree-data-ref.c (revision 220259)
> +++ gcc/tree-data-ref.c (working copy)
> @@ -973,6 +973,24 @@
> fold_convert (ssizetype, memoff));
>   memoff = build_int_cst (TREE_TYPE (memoff), 0);
> }
> + /* Adjust the offset so it is a multiple of the access type
> +size and thus we separate bases that can possibly be used
> +to produce partial overlaps (which the access_fn machinery
> +cannot handle).  */
> + double_int rem;
> + if (TYPE_SIZE_UNIT (TREE_TYPE (ref))
> + && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (ref))) == INTEGER_CST
> + && !integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (ref
> +   rem = tree_to_double_int (off).mod
> +(tree_to_double_int (TYPE_SIZE_UNIT (TREE_TYPE (ref))), 
> false,
> + TRUNC_MOD_EXPR);
> + else
> +   /* If we can't compute the remainder simply force the initial
> +  condition to zero.  */
> +   rem = tree_to_double_int (off);
> + off = double_int_to_tree (ssizetype, tree_to_double_int (off) - 
> rem);
> + memoff = double_int_to_tree (TREE_TYPE (memoff), rem);
> + /* And finally replace the initial condition.  */
>   access_fn = chrec_replace_initial_condition
>   (access_fn, fold_convert (orig_type, off));
>   /* ???  This is still not a suitable base object for
> 
>

[Bug tree-optimization/64829] [ARM] ICE at -O3 in vect_get_vec_def_for_stmt_copy

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 30 09:22:17 2015
New Revision: 220275

URL: https://gcc.gnu.org/viewcvs?rev=220275&root=gcc&view=rev
Log:
2015-01-30  Richard Biener  

PR tree-optimization/64829
* tree-vect-patterns.c (vect_handle_widen_op_by_const): Do
not add a widening conversion pattern but hand off extra
widenings to callers.
(vect_recog_widen_mult_pattern): Handle extra widening produced
by vect_handle_widen_op_by_const.
(vect_recog_widen_shift_pattern): Likewise.
(vect_pattern_recog_1): Remove excess vertical space in dumping.
* tree-vect-stmts.c (vect_mark_stmts_to_be_vectorized): Likewise.
(vect_init_vector_1): Likewise.
(vect_get_vec_def_for_operand): Likewise.
(vect_finish_stmt_generation): Likewise.
(vectorizable_load): Likewise.
(vect_analyze_stmt): Likewise.
(vect_is_simple_use): Likewise.

* gcc.dg/vect/pr64829.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr64829.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/64829] [ARM] ICE at -O3 in vect_get_vec_def_for_stmt_copy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ipa/64872] New: [5 Regression] ICE: Segmentation fault during Chromium PGO build

[trippels at gcc dot gnu.org]

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

Bug ID: 64872
   Summary: [5 Regression] ICE: Segmentation fault during Chromium
PGO build
   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: marxin at gcc dot gnu.org

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

Chromium build fails during -fprofile-use phase:

markus@x4 /tmp % g++ -c -O2 -fprofile-use -fprofile-correction -fno-exceptions
-fno-rtti -std=gnu++11 pickle.ii
../../base/pickle.cc:372:1: internal compiler error: Segmentation fault
0xc9823f crash_signal
../../gcc/gcc/toplev.c:381
0xa1811a aggregate_value_p(tree_node const*, tree_node const*)
../../gcc/gcc/function.c:2037
0xa1ec4e allocate_struct_function(tree_node*, bool)
../../gcc/gcc/function.c:4788
0x903823 cgraph_node::create_wrapper(cgraph_node*)
../../gcc/gcc/cgraphunit.c:2407
0x129f8cb ipa_icf::sem_function::merge(ipa_icf::sem_item*)
../../gcc/gcc/ipa-icf.c:766
0x12a4ca1 ipa_icf::sem_item_optimizer::merge_classes(unsigned int)
../../gcc/gcc/ipa-icf.c:2383
0x12a9a7c ipa_icf::sem_item_optimizer::execute()
../../gcc/gcc/ipa-icf.c:1734
0x12aa311 ipa_icf_driver
../../gcc/gcc/ipa-icf.c:2461
0x12aa311 ipa_icf::pass_ipa_icf::execute(function*)
../../gcc/gcc/ipa-icf.c:2509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

As expected -fno-ipa-icf "fixes" the issue.

[Bug libstdc++/64865] std::allocator::construct/destroy not called for specialization of std::allocator

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Casey Carter from comment #0)
> * Close this bug report as WONTFIX since it is horrible design to specialize
> std::allocator instead of declaring a new allocator type; given that
> container implementations are free to rebind to a different specialization,
> there is no guarantee that functionality added to a user-defined
> specialization will even be used.

This.

[Bug debug/64817] [5 Regression] compilation hangs at -O3 with -g enabled on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Alex mentioned this is related to PR48866 and it is also related to PR56510. 
Since the latter, we actually break too complex debug insn expressions into
simpler ones (with maximum depth of 4), and it would do its job in this case
too, but the problem is that already the simplify_gen_* has the undesirable
complexity on the expressions.

[Bug jit/64873] New: jit testsuite failures on powerpc64le-unknown-linux-gnu

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 64873
   Summary: jit testsuite failures on
powerpc64le-unknown-linux-gnu
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

With r220259 (aka 5bb1df18a77ddc8bae7dd610128fec21b64a2ca0),
"make check-jit" fails some testcases with:

jit.sum:358:FAIL: test-accessing-union.c.exe killed: 14656 exp7 0 0 CHILDKILLED
SIGILL {illegal instruction}
jit.sum:857:FAIL: test-combination.c.exe killed: 16447 exp7 0 0 CHILDKILLED
SIGILL {illegal instruction}
jit.sum:1036:FAIL: test-dot-product.c.exe killed: 15939 exp8 0 0 CHILDKILLED
SIGILL {illegal instruction}
jit.sum:1781:FAIL: test-expressions.c.exe killed: 14878 exp7 0 0 CHILDKILLED
SIGILL {illegal instruction}
jit.sum:1842:FAIL: test-functions.c.exe killed: 16230 exp7 0 0 CHILDKILLED
SIGILL {illegal instruction}
jit.sum:2417:FAIL: test-nested-loops.c.exe killed: 14676 exp7 0 0 CHILDKILLED
SIGILL {illegal instruction}
jit.sum:2674:FAIL: test-threads.c.exe killed: 16692 exp7 0 0 CHILDKILLED SIGILL
{illegal instruction}

(I also see PR jit/64752)

Configured with:
   --enable-host-shared --enable-languages=jit,c++ --disable-bootstrap
--enable-checking=release --disable-multilib
Build compiler:
  gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
as:
GNU assembler version 2.23.52.0.1 (ppc64le-redhat-linux) using BFD version
version 2.23.52.0.1-26.bs4 20130226


Setting:
  gcc_jit_context_set_bool_option (
ctxt,
GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES,
1);
to debug.

For test-accessing-union.c.exe, SIGILL happens here:
#0  0x3fffb0100714 in test_union (i=42) from /tmp/libgccjit-lh83IX/fake.so
(gdb) disassemble
Dump of assembler code for function test_union:
   0x3fffb0100710 <+0>: rldicr  r9,r3,32,31
=> 0x3fffb0100714 <+4>: mtvsrd  vs1,r9
   0x3fffb0100718 <+8>: xscvspdpn vs1,vs1
   0x3fffb010071c <+12>:blr
   0x3fffb0100720 <+16>:.long 0x0
   0x3fffb0100724 <+20>:.long 0x0
   0x3fffb0100728 <+24>:.long 0x0
End of assembler dump.

The corresponding fake.s file was:
.file   "fake.c"
.machine power8
.abiversion 2
.section".toc","aw"
.section".text"
.Ltext0:
.cfi_sections   .debug_frame
.align 2
.p2align 4,,15
.globl test_union
.type   test_union, @function
test_union:
.LFB0:
.cfi_startproc
.LVL0:
sldi 9,3,32
mtvsrd 1,9
xscvspdpn 1,1
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
.LFE0:
.size   test_union,.-test_union
.Letext0:
.section.debug_info,"",@progbits
.Ldebug_info0:
  (...snip...)

test-expressions.c.exe dies in this jit-generated code:

Program received signal SIGILL, Illegal instruction.
(gdb) disassemble
Dump of assembler code for function test_cast_from_float_to_int:
   0x3fffb00d1260 <+0>: fctiwz  f1,f1
=> 0x3fffb00d1264 <+4>: mfvsrd  r3,vs1
   0x3fffb00d1268 <+8>: extsw   r3,r3
   0x3fffb00d126c <+12>:blr
   0x3fffb00d1270 <+16>:.long 0x0
   0x3fffb00d1274 <+20>:.long 0x0
   0x3fffb00d1278 <+24>:.long 0x0
End of assembler dump.

test-dot-product.c.exe dies in this ahead-of-time compiled
code in "verify_code":

   0x100032bc <+292>:   stfdf1,104(r31)
   0x100032c0 <+296>:   lfd f12,104(r31)
   0x100032c4 <+300>:   lfd f0,104(r31)
=> 0x100032c8 <+304>:   mfvsrd  r4,vs12
   0x100032cc <+308>:   fmr f1,f0
   0x100032d0 <+312>:   addis   r3,r2,-2
   0x100032d4 <+316>:   addir3,r3,31384
   0x100032d8 <+320>:   bl  0x10002168 
   0x100032dc <+324>:   lfd f12,104(r31)
   0x100032e0 <+328>:   addis   r9,r2,-2

[Bug libstdc++/61458] std::aligned_storage is bigger than expected

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||paolo at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
The problem is the default value of the _Align parameter, which comes from
alignof(__aligned_storage_msa<_Len>::__type) which is always the maximum
alignment:

  template
struct __aligned_storage_msa
{ 
  union __type
  {
unsigned char __data[_Len];
struct __attribute__((__aligned__)) { } __align; 
  };
};

That effectively ignores _Len and will always have 16-byte alignment, which
means sizeof(aligned_storage) is always at least 16 bytes.

Should the attribute be using __aligned__(_Len) or does that do the wrong thing
in some cases?

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|5.0 |6.0

--- Comment #10 from Jonathan Wakely  ---
Not happening this release either.

[Bug libstdc++/64865] std::allocator::construct/destroy not called for specialization of std::allocator

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
(In reply to Casey Carter from comment #0)
> * Close this bug report as WONTFIX since it is horrible design to specialize
> std::allocator instead of declaring a new allocator type; given that
> container implementations are free to rebind to a different specialization,
> there is no guarantee that functionality added to a user-defined
> specialization will even be used.

Since the allocator_type member must be the Alloc template argument provided by
the user and not any rebound types, though, it seems to me that it is in fact
guaranteed that their versions of construct() and destroy() will be called, as
the paragraph you cite requires the use of
allocator_traits::construct and
allocator_traits::destroy.

[Bug jit/64873] jit testsuite failures on powerpc64le-unknown-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Supposedly this is another case of the default options not being passed in.
ppc64le defaults to -mcpu=power8, but the hw Fedora tests this on is still
power7+, so we use --with-cpu-64=power7 --with-tune-64=power8, but supposedly
that -mcpu=power7 is passed only from the driver.

[Bug target/15184] [4.8/4.9 Regression] Direct access to byte inside word not working with -march=pentiumpro

[uros at gcc dot gnu.org]

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

--- Comment #34 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jan 30 10:53:53 2015
New Revision: 220277

URL: https://gcc.gnu.org/viewcvs?rev=220277&root=gcc&view=rev
Log:
PR target/15184
* gcc.target/i386/pr15184-1.c: Compile for ia32 target only.
(dg-options): Remove -m32.
(dg-final): Scan for "movb %al" only.
* gcc.target/i386/pr15184-2.c: Ditto.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr15184-1.c
trunk/gcc/testsuite/gcc.target/i386/pr15184-2.c

[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")

[dmalcolm at gcc dot gnu.org]

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

--- Comment #20 from David Malcolm  ---
Patches posted for review as:
  https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02704.html

[Bug libstdc++/64865] std::allocator::construct/destroy not called for specialization of std::allocator

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to TC from comment #2)
> Since the allocator_type member must be the Alloc template argument provided
> by the user and not any rebound types, though,

N.B. libstdc++ supports std::vector> and so always
rebinds the _Alloc parameter to get an allocator for the value_type. That
doesn't change your argument though, because it will rebind it to
allocator and that's  the type that's specialized.

> it seems to me that it is in
> fact guaranteed that their versions of construct() and destroy() will be
> called, as the paragraph you cite requires the use of
> allocator_traits::construct and
> allocator_traits::destroy.

That's a defect, see http://cplusplus.github.io/LWG/lwg-active.html#2218

That defect is a problem for node-based containers, but in principle any
container should be able to use
allocator_traits::rebind_traits::construct()
to construct the elements, in which case your allocator
specialization is not used.

[Bug libstdc++/64275] Warnings when linking GCC go1: "(virtual table of) type 'struct X' violates one definition rule"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The simplest way to solve this might be to replace the extern declarations in
ios_init.cc such as:

  extern stdio_sync_filebuf buf_cout_sync;

with a pointer:

  extern stdio_sync_filebuf* buf_cout_sync_p;

then in globals_io.cc do:

  stdio_sync_filebuf* buf_cout_sync_p =
reintepret_cast*>(buf_cout_sync);

That way we have an explicit cast rather than just relying on the linker
finding the symbol.

[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug libstdc++/61458] std::aligned_storage is bigger than expected

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
P.S. this isn't an urgent problem for the library, as we don't use
aligned_storage internally, we always use __aligned_buffer which
specifies the alignment explicitly rather than relying on the 16-byte default.

[Bug ipa/64872] [5 Regression] ICE: Segmentation fault during Chromium PGO build

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can

[rguenth at gcc dot gnu.org]

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

--- Comment #32 from Richard Biener  ---
"So I take the other way around by passing the IV's ssa_name into
scev_probably_wraps_p along call sequence
"idx_find_step->convert_affine_scev->scev_probably_wraps".  Since the IV's
ssa_name is tagged with right range information, we can use it when proving
there is no overflow/wrap in src scev."

I'm not sure that this is always correct - is the name we ask
scev_probably_wraps
on always equal to the IV?  Is it never offsetted?  I think that we need a
soultion that involves tracking of range information all the way through
SCEV analysis and thus have it on the CHREC itself.


As for the other things - yes, there are multiple places where we lose sign
information and STEP is just one example (I _think_ I made DR_STEP for
data-ref analysis forced signed at some point).

Promoting the array index to a word_mode type sounds interesting, it of course
only makes sense for previously signed types - otherwise you just get another
conversion in the way.  Of course with GCC you will likely run into the issue
that this promotion is cancelled by the forced conversion to sizetype, so
you'll end up with unsigned word_mode again.  Btw - this was kind of my
suggestion with making get_inner_reference return *POFFSET as ssizetype type,
not sizetype (callers might not expect this, so for experimenting just
wrap get_inner_reference in sth converting that back to sizetype for all
callers but IVOPTs and tree-affine.c (and eventually tree-scalar-evolution.c)).

[Bug ipa/64872] [5 Regression] ICE: Segmentation fault during Chromium PGO build

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug debug/64817] [5 Regression] compilation hangs at -O3 with -g enabled on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

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 34626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34626&action=edit
gcc5-pr64817.patch

Untested fix.  This inserts debug temporaries into too deep TER chains from
debug stmts, so that there is better sharing of the debug temporaries and the
depths for the simplifications aren't that deep.

[Bug fortran/64854] No bound check for explicit-shape arrays

[bugs at stellardeath dot org]

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

--- Comment #7 from Lorenz Hüdepohl  ---
> Use valgrind or -fsanitize=address to detect this kind of
> memory problems.

I can live with that, thanks for your comments!

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

  Attachment #34487|0   |1
is obsolete||

--- Comment #5 from Tobias Burnus  ---
Created attachment 34627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34627&action=edit
Updated test case (part 1/2): [main file] compile with g++ -fsanitize=vptr

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  ---
Created attachment 34628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34628&action=edit
Updated test case (part 2/2): [aux file]

Updated test case. The first file matches what the original source code had:

  #pragma interface
in the header and
  #pragma implementation "file.h"

in the implementation. However, "class LogListener" is only forward declared in
the header file - and in the actual implementation also includes
"LogListener.h", which also has "#pragma interface".


The LogListener.cc file includes LogListener.h and has "#pragma
implementation".

For my "aux file", no symbol is generated at all. For the real-world
LogListener.cc, a "V typeinfo for LogListener" is created and "W
LogListener::LogListener()". (In the original file, a class inheriting from
LogListener is declared (.h) and implemented (.cc).)

[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can you still reproduce it?

[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #7 from Dodji Seketeli  ---
I have proposed the patch for review at
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02693.html

[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
And if yes, can it be also reproduced with building the pch file with
-save-temps?  Then perhaps you could attach the preprocessed source from which
the pch is compiled, and tweak qhash.cpp to preprocess it too, but remove the
pch header part from it and replace with include, then preprocess again.

[Bug gcov-profile/64874] New: gcov's magic number possibly increasing too quickly with new gcc version numbering scheme.

[rearnsha at gcc dot gnu.org]

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

Bug ID: 64874
   Summary: gcov's magic number possibly increasing too quickly
with new gcc version numbering scheme.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org

A comment in gcov-io.h reads:

"   Although the ident and version are formally 32 bit numbers, they
   are derived from 4 character ASCII strings.  The version number
   consists of the single character major version number, a two
   character minor version number (leading zero for versions less than
   10), and a single character indicating the status of the release.
   That will be 'e' experimental, 'p' prerelease and 'r' for release.
   Because, by good fortune, these are in alphabetical order, string
   collating can be used to compare version strings.  Be aware that
   the 'e' designation will (naturally) be unstable and might be
   incompatible with itself.  For gcc 3.4 experimental, it would be
   '304e' (0x33303465).  When the major version reaches 10, the
   letters A-Z will be used.  Assuming minor increments releases every
   6 months, we have to make a major increment every 50 years.
   Assuming major increments releases every 5 years, we're ok for the
   next 155 years -- good enough for me."

With the move to increasing the major version number with every year, we are
going to exhaust this magic number scheme much more rapidly than cited above.

Perhaps we should change how the magic number is generated.

[Bug ipa/64813] [5 Regression] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #12 from Martin Liška  ---
Problem is caused by a function pair where we decide to create a thunk.
Unfortunately, alias of the thunk is noreturn function, because of:

function ...
{
  ...
  :
  std::__throw_out_of_range ("_Map_base::at");

}

I'been testing patch that does not create retval and return gimple statement.

Martin

[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
While retesting I came across this seemingly bizarre issue:

markus@x4 /tmp % touch qt_pch.ii
markus@x4 /tmp % g++ -w -O2 -std=c++0x -x c++-header -c qt_pch.ii
qt_pch.ii:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

==17157== Invalid read of size 1
==17157==at 0xCBB825: ggc_get_size(void const*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0xBE7A71: gt_pch_note_object(void*, void*, void (*)(void*,
void*, void (*)(void*, void*), void*)) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0xBE7D4B: gt_pch_nx_cpp_macro(void*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0xC1EDFF: gt_pch_nx_lang_tree_node(void*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0xB728E0: gt_pch_nx_string_pool_data(void*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0xBE7436: gt_pch_save(_IO_FILE*) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0xC10BBB: c_common_write_pch() (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0x5C2817: ??? (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0xCB561F: compile_file() [clone .lto_priv.2265] (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0xC2D8FD: toplev::main(int, char**) (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==by 0xC2C8BC: main (in
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/cc1plus)
==17157==  Address 0x2e is not stack'd, malloc'd or (recently) free'd
==17157== 

The crash only happens with a LTO/PGO bootstrapped compiler using
checking=release.

A --disable-bootstrap compiler with debug-info shows:

markus@x4 /tmp % valgrind --track-origins=yes --trace-children=yes
/var/tmp/gcc_test/usr/local/bin/g++ -w -O2 -std=c++0x -x c++-header -c
qt_pch.ii
==17702== Memcheck, a memory error detector
==17702== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17702== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==17702== Command: /var/tmp/gcc_test/usr/local/bin/g++ -w -O2 -std=c++0x -x
c++-header -c qt_pch.ii
==17702== 
==17703== Memcheck, a memory error detector
==17703== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17703== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==17703== Command:
/var/tmp/gcc_test/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus
-quiet -iprefix
/var/tmp/gcc_test/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/
-D_GNU_SOURCE qt_pch.ii -quiet -dumpbase qt_pch.ii -mtune=generic -march=x86-64
-auxbase qt_pch -O2 -w -std=c++11 -o /tmp/ccjRTklN.s --output-pch=qt_pch.ii.gch
==17703== 
==17703== Syscall param write(buf) points to uninitialised byte(s)
==17703==at 0x4F8A370: __write_nocancel (in /lib64/libc-2.20.90.so)
==17703==by 0x4F2B3EE: _IO_file_write@@GLIBC_2.2.5 (in
/lib64/libc-2.20.90.so)
==17703==by 0x4F2A9F2: new_do_write (in /lib64/libc-2.20.90.so)
==17703==by 0x4F2C2F0: _IO_do_write@@GLIBC_2.2.5 (in
/lib64/libc-2.20.90.so)
==17703==by 0x4F2BA66: _IO_file_xsputn@@GLIBC_2.2.5 (in
/lib64/libc-2.20.90.so)
==17703==by 0x4F2167A: fwrite (in /lib64/libc-2.20.90.so)
==17703==by 0x88647C: ggc_pch_write_object(ggc_pch_data*, _IO_FILE*, void*,
void*, unsigned long, bool) (ggc-page.c:2451)
==17703==by 0xA2C1E0: gt_pch_save(_IO_FILE*) (ggc-common.c:566)
==17703==by 0x861FEC: c_common_write_pch() (c-pch.c:197)
==17703==by 0x6E4E8C: cp_write_global_declarations() (decl2.c:4400)
==17703==by 0xC96DD3: compile_file() (toplev.c:608)
==17703==by 0x5F84EE: do_compile (toplev.c:2063)
==17703==by 0x5F84EE: toplev::main(int, char**) (toplev.c:2161)
==17703==  Address 0x4049005 is not stack'd, malloc'd or (recently) free'd
==17703==  Uninitialised value was created by a heap allocation
==17703==at 0x4028C70: malloc (vg_replace_malloc.c:296)
==17703==by 0x135C257: xmalloc (xmalloc.c:147)
==17703==by 0x132DC8A: _cpp_init_tokenrun (lex.c:2008)
==17703==by 0x132C28A: cpp_create_reader(c_lang, ht*, line_maps*)
(init.c:238)
==17703==by 0x85F85C: c_common_init_options(unsigned int,
cl_decoded_option*) (c-opts.c:234)
==17703==by 0x5F7F9D: toplev::main(int, char**) (toplev.c:2136)
==17703==by 0x5F9199: main (main.c:39)

[Bug c++/64875] New: -Winline does not report C++ methods

[daniel.gutson at tallertechnologies dot com]

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

Bug ID: 64875
   Summary: -Winline does not report C++ methods
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.gutson at tallertechnologies dot com

The following code misses the warning:

#include 

struct PP
{
inline void m();
};

int main()
{
PP pp;
pp.m();
}

inline void PP::m()
{
std::cout << "hola" << std::endl;
}

Invoke:
  g++ -Wall -Wextra -pedantic -ggdb3 -std=c++11 -Winline winline.cpp
No warnings emitted.

However:

objdump -dC ./a.out |grep "PP"
  40086c:e8 59 00 00 00   callq  4008ca 
004008ca :

If no one is available, assign this to me (though I'm not sure when I will have
time to address this).

[Bug ada/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).

[charlet at gcc dot gnu.org]

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

--- Comment #12 from Arnaud Charlet  ---
Author: charlet
Date: Fri Jan 30 15:13:15 2015
New Revision: 220285

URL: https://gcc.gnu.org/viewcvs?rev=220285&root=gcc&view=rev
Log:
2015-01-30  Tristan Gingold  

PR ada/64349
* env.c: Move vxworks and darwin includes out of #ifdef IN_RTS.


Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/env.c

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at acm dot org

--- Comment #10 from Nathan Sidwell  ---
What's the visibility on __gcov_merge_add?  All those functions should have
hidden visibility. I see:
extern void __gcov_merge_add (gcov_type *, unsigned) ATTRIBUTE_HIDDEN;

Could you give me the recipe for getting and building firefox in this manner?

To answer the 'how's it supposed to work' question.  Each DSO with coverage
needs contains its own set of gcov routines -- all hidden.  The linkage between
each dso is in the data -- each (compatible) dso chains onto the gcov_master
variable.  That is not hidden, and one will win in the resultant process.  Does
that make sense?

[Bug ada/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

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

--- Comment #13 from Arnaud Charlet  ---
Should be fixed, hopefully

[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

[ktietz at gcc dot gnu.org]

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

--- Comment #3 from Kai Tietz  ---
(In reply to Jakub Jelinek from comment #2)
> Reduced testcase:
> 
> inline void
> foo (void)
> {
> }
> 
> __attribute__ ((__dllimport__))
> void foo (void);
> 
> void
> bar (void)
> {
>   foo ();
> }
> 
> No options are needed, reproduced with x86_64-linux -> x86_64-mingw32 cross.
> ICEs the same even with an extra extern void foo (void); prototype above the
> inline, and no matter whether -std=gnu89 or -std=c11 is used.
> Kai, is this even meant to be valid (i.e. shouldn't we reject this - adding
> dllimport attribute after inline fn definition)?  And, is it really a
> regression?  Don't have time to build cross-compilers for older gcc
> versions, perhaps you have some older ones around?

I think this scenario is valid.  Of course it is better style for having first
the prototype and then its inline-function.

So by changing sample this way:

__attribute__ ((__dllimport__))
void foo (void);

inline void
foo (void)
{
}

void
bar (void)
{
  foo ();
}

There is no ICE.  The point here is that dllimport indicates that function is
external, but by the dllimport-attribute 'function_and_variable_visibility'
pass gets confused. In symtab_node::noninterposable_alias() we assert on
'decl_binds_to_current_def_p' returning true, which is of course the case for
the inline-case.

[Bug target/64212] [4.9/5 Regression] ICE [in noninterposable_alias, at symtab.c:1706]

[ktietz at gcc dot gnu.org]

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

--- Comment #4 from Kai Tietz  ---
A side-note:  Of course the dllimport attribute is part of the prototype.  So
for C case it would be consistent to have the dllimport-attribute also
specified for the inline, which gets rejected.  This reject might be doubtful
as an inline-function isn't necessarily inlined, and so the function gets
called.
A second side-note:  This issue is only happening for C compiler.  For C++
semantics of inline is different, and sample-code works as expected.

[Bug c++/63356] Compilation failure where clang does not have problems

[fiesh at zefix dot tv]

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

--- Comment #14 from fiesh at zefix dot tv ---
Bounty: EUR 150

I'd like to try something new and place a bounty on this issue.  In order to
collect it, you have to provide a patch that is accepted into 4.9 and 5.  You
also need to be able to write a bill with explicit VAT (we are based in
Germany).  Alternatively, I'll donate the money to any charitable use of your
choice, again subject to requiring a receipt from the charity receiving it.

[Bug jit/64873] jit testsuite failures on powerpc64le-unknown-linux-gnu

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
I think this is misconfigurfation at my end; sorry.

I'm on power7 hw, emulating via qemu, and I did *not*
configure with the options suggested by Jakub in comment #1;
so I think I'm misconfiguring the build.

A minimal reproducer for the behavior I'm seeing:

$ cat main.c
#include 

union int_or_float
{
  int as_int;
  float as_float;
};

float  __attribute__ ((noinline))
test_union (int i)
{
  union int_or_float u;
  u.as_int = i;
  return u.as_float;
}

int
main (int argc, char **argv)
{
  union int_or_float u;

  float f_result = test_union (42);
  u.as_float = f_result;

  assert (u.as_int == 42);
  return 0;
}

(eof)

Compiling with -O1 or above, with -mcpu=power8:
gcc -O1 main.c -mcpu=power8
I get SIGILL:
(gdb) disassemble
Dump of assembler code for function test_union:
   0x1624 <+0>: rldicr  r9,r3,32,31
=> 0x1628 <+4>: mtvsrd  vs1,r9
   0x162c <+8>: xscvspdpn vs1,vs1
   0x1630 <+12>:blr
   0x1634 <+16>:.long 0x0
   0x1638 <+20>:.long 0x0
   0x163c <+24>:.long 0x0

presumably due to not actually being on power8.

I'll rerun the JIT build and tests, with the correct configuration flags for
this hardware, and  with the candidate patches for PR jit/64810 (so that the
jit honors them).

[Bug go/64876] New: Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)

[boger at us dot ibm.com]

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

Bug ID: 64876
   Summary: Regressions in gcc-testresults for powerpc64 gccgo in
5.0 due to change for static chain for closures
(219776)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: boger at us dot ibm.com
CC: cmang at google dot com
Target: powerpc64

Many new failures appear in gcc-testresults for gccgo on powerpc64 after the
change was added to use the static chain for closures.  Regressions do not
occur with powerpc64le.  (Probably due to the different ABIs?) There are 30+
regressions in the go tests and 100+ regressions in the libgo testsuite.

The first gcc-testresults page with these regressions is:
 https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg01797.html

The failures I've seen have a message with a signal 11:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x8]

goroutine 16 [running]:
main.$nested0
   
/home/boger/gccgo.work/r219749/src/gcc/testsuite/go.test/test/escape.go:152
main.for_escapes3
   
/home/boger/gccgo.work/r219749/src/gcc/testsuite/go.test/test/escape.go:155
main.main
   
/home/boger/gccgo.work/r219749/src/gcc/testsuite/go.test/test/escape.go:204
created by main
/home/boger/gccgo.work/r219749/bld/../src/libgo/runtime/go-main.c:42
FAIL: go.test/test/escape.go execution,  -O2 -g

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Yep, I think the problem is that each of DSOs will have its own set of infos
that will point to its own gcov_merge_add that calls its own gcov_io routines.

Now the winning gcov will walk the list but as soon as it will hit entry from
other DSO it will indirectly call the wrong one.

gcov_merge_add is hidden in my setup.

[Bug c++/64877] New: strange warning message from -Waddress

[tromey at gcc dot gnu.org]

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

Bug ID: 64877
   Summary: strange warning message from -Waddress
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org

I found a spot in firefox that tries to prevent hiding
using:

explicit ScopedGLWrapper(GLContext* gl)
: mIsUnwrapped(false)
, mGL(gl)
{
MOZ_ASSERT(&ScopedGLWrapper::Unwrap == &Derived::Unwrap);

[...]

void Unwrap() {
...
}

gcc 5 warns about this assert:

/home/tromey/firefox-git/gecko-dev/gfx/gl/ScopedGLHelpers.h:35:54: error: the
address of ‘void mozilla::gl::ScopedGLWrapper::Unwrap() [with Derived
= mozilla::gl::ScopedGLState]’ will never be NULL [-Werror=address]
 MOZ_ASSERT(&ScopedGLWrapper::Unwrap == &Derived::Unwrap);
  ^

The message here is strange.  Whether or not the address can be NULL
is not an issue.  I don't see why -Waddress ought to warn here at all.

[Bug c++/20710] g++ should warn when hiding non-virtual method in base class

[tromey at gcc dot gnu.org]

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

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #8 from Tom Tromey  ---
It would be nice to have a way to prevent hiding.

See the partial example in bug 64877.  Here, gcc 5
warns about the construct used to prevent hiding.
However, "final" will not work as the function in question
is non-virtual.

The class in question is a base class, so it seems rather
strange to make the function "virtual final".  And, while
not an issue in this particular case, that would in some
cases introduce a vtable where none was previously needed.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  ---
BTW the following fix the issue for me
Index: gcov-io.c
===
--- gcov-io.c   (revision 220230)
+++ gcov-io.c   (working copy)
@@ -39,7 +39,7 @@ static void gcov_allocate (unsigned);
 /* Optimum number of gcov_unsigned_t's read from or written to disk.  */
 #define GCOV_BLOCK_SIZE (1 << 10)

-GCOV_LINKAGE ATTRIBUTE_HIDDEN struct gcov_var
+struct gcov_var
 {
   FILE *file;
   gcov_position_t start;   /* Position of first byte of block */

indeed we are mixing up the gcov-io routines from wrong unit via wrong mergers.
I suppose either we need to pass the io routine as parameter by pointer or
modify gcov_io to actually contain indexes into merge routine list instead of
direct pointers?

[Bug c++/64867] warning for passing non-POD to varargs function

[tromey at gcc dot gnu.org]

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

--- Comment #5 from Tom Tromey  ---
(In reply to Jason Merrill from comment #3)
> Passing a non-POD to a varargs function is conditionally-supported, with
> implementation-defined semantics.  In GCC 5 it's supported and treated like
> normal pass-by-value.  You can get a diagnostic about it with
> -Wconditionally-supported.

I tried this today and it does not work with the test case in comment #4.

pokyo. gcc --version
gcc (GCC) 5.0.0 20150129 (experimental)
Copyright (C) 2015 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.

pokyo. g++ --std=c++11 --syntax-only -Wall -Wconditionally-supported q.cc
pokyo.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #13 from Nathan Sidwell  ---
No.  Each dso's gcov machinery is individually invoked.  There should be no
cross-dso accessing of data (beyond the global chain of dso)

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #14 from Nathan Sidwell  ---
Jan, I'm fairly sure that even though your fix makes things work, it is wrong. 
You're  at the very least exposing an internal API across the DSO boundary,
which should not be exposed.

[Bug c++/64867] warning for passing non-POD to varargs function

[tromey at gcc dot gnu.org]

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

--- Comment #6 from Tom Tromey  ---
Also, -Wconditionally-supported triggers other warning as well.
It would be more convenient if different warnings were individually
controllable; and then something like -Wconditionally-supported
would act as if I'd specified all the sub-options.

[Bug c++/64867] warning for passing non-POD to varargs function

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Tom Tromey from comment #5)
> (In reply to Jason Merrill from comment #3)
> > Passing a non-POD to a varargs function is conditionally-supported, with
> > implementation-defined semantics.  In GCC 5 it's supported and treated like
> > normal pass-by-value.  You can get a diagnostic about it with
> > -Wconditionally-supported.
> 
> I tried this today and it does not work with the test case in comment #4.
> 
> pokyo. gcc --version
> gcc (GCC) 5.0.0 20150129 (experimental)
> Copyright (C) 2015 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.
> 
> pokyo. g++ --std=c++11 --syntax-only -Wall -Wconditionally-supported q.cc
> pokyo.

Are you sure that class is not trivial which is why gcc is not warning about
it?  C++11 does not really have pod and non-pod any more but rather trivial and
non-trivial and the rules has chnaged with respect of constructures.

[Bug c++/64867] warning for passing non-POD to varargs function

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm . It does
look like gcc is implementing the correct new pod rules and clang is not.

[Bug tree-optimization/64878] New: [5 Regression] Miscompilation of nntpgrab

[jakub at gcc dot gnu.org]

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

Bug ID: 64878
   Summary: [5 Regression] Miscompilation of nntpgrab
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org

Starting with r218451 gcc miscompiles at -O2 on x86_64-linux (both -m64 and
-m32) following testcase:

struct A { int a1; };
struct B { char *b1; int b2; int b3; };
struct C { char *c1; int c2; struct B *c3; };
extern struct A *f1 (char *s);
static struct A *f2 (struct C *x);
__attribute__ ((noinline, noclone)) int f3 (struct A *x, struct A *z) { asm
volatile ("" : : "g" (x), "g" (z) : "memory"); return 0; }
__attribute__ ((noinline, noclone)) void f4 (struct A *x, char *y, struct A *z)
{ asm volatile ("" : : "g" (x), "g" (z), "g" (y) : "memory"); }
__attribute__ ((noinline, noclone)) struct B *f5 (void) { static char b[32];
static struct B f3 = { b, 0, 32 }; return &f3; }
__attribute__ ((noinline, noclone)) int f6 (struct B *p, char *w, int z) { asm
volatile ("" : : "g" (p), "g" (w), "g" (z) : "memory"); return 0; }
__attribute__ ((noinline, noclone)) void f7 (struct B *p) { asm volatile ("" :
: "g" (p) : "memory"); }
__attribute__ ((noinline, noclone)) void f8 (struct B *p) { asm volatile ("" :
: "g" (p) : "memory"); }
__attribute__ ((noinline, noclone)) void f9 (struct A *x) { asm volatile ("" :
: "g" (x) : "memory"); }
__attribute__ ((noinline, noclone)) struct A *f10 (void) { static struct A j;
asm volatile ("" : :  : "memory"); return &j; }
__attribute__ ((noinline, noclone)) struct A *f11 (void) { static struct A j;
asm volatile ("" : :  : "memory"); return &j; }
__attribute__ ((noinline, noclone)) struct A *f12 (int b) { static struct A j;
asm volatile ("" : : "g" (b) : "memory"); return &j; }
__attribute__ ((noinline, noclone)) struct A *f13 (int i) { static struct A j;
asm volatile ("" : : "g" (i) : "memory"); return &j; }
__attribute__ ((noinline, noclone)) struct A *f14 (double d) { static struct A
j; asm volatile ("" : : "g" (&d) : "memory"); return &j; }
__attribute__ ((noinline, noclone)) struct A *f15 (char *s) { static struct A
j; asm volatile ("" : : "g" (s) : "memory"); return &j; }
char *t = "0123456789abcdef";
char *u = "0123456789.+-e";

__attribute__ ((noinline, noclone)) struct A *
f1 (char *s)
{
  struct C f;
  struct A *o;
  f.c1 = s;
  f.c2 = 0;
  f.c3 = f5 ();
  o = f2 (&f);
  f8 (f.c3);
  return o;
}

static struct A *
f2 (struct C *x)
{
  int a, b, e = 0;
  struct A *f = 0, *o;
  char *g = 0;
  char h = '\0';
  int i = 0, j = 0;
  a = 0;
  b = 1;
  char c;
  do
{
  c = x->c1[x->c2];
  switch (a)
{
case 0:
  if (c == ' ')
x->c2++;
  else if (c == '/')
{
  a = 4;
  j = x->c2++;
}
  else
a = b;
  break;
case 1:
  switch (c)
{
case '{':
  a = 0;
  b = 15;
  f = f10 ();
  x->c2++;
  break;
case '[':
  a = 0;
  b = 13;
  f = f11 ();
  x->c2++;
  break;
case 'N':
case 'n':
  a = 3;
  j = x->c2++;
  break;
case '"':
case '\'':
  h = c;
  f7 (x->c3);
  a = 8;
  j = ++x->c2;
  break;
case 'T':
case 't':
case 'F':
case 'f':
  a = 11;
  j = x->c2++;
  break;
case '0' ... '9':
case '-':
  i = 0;
  a = 12;
  j = x->c2++;
  break;
default:
  e = 1;
  goto out;
}
  break;
case 2:
  goto out;
case 3:
  if (__builtin_strncmp ("null", x->c1 + j, x->c2 - j))
{
  e = 2;
  goto out;
}
  if (x->c2 - j == 4)
{
  f = 0;
  b = 2;
  a = 0;
}
  else
x->c2++;
  break;
case 4:
  if (c == '*')
a = 5;
  else if (c == '/')
a = 6;
  else
{
  e = 8;
  goto out;
}
  x->c2++;
  break;
case 5:
  if (c == '*')
a = 7;
  x->c2++;
  break;
case 6:
  if (c == '\n')
a = 0;
  x->c2++;
  break;
case 7:
  if (c == '/')
a = 0;
  else
a = 5;
  x->c2++;
  break;
case 8:
  if (c == h)
{
  f6 (x->c3, x->c1 + j, x->c2 - j);
  f = f15 (x->c3->b1);
  b = 2;
  a = 0;
}
  else if (c == '\\')
{
  b = 8;
  a = 9;
}
  x->c2++;
  break;
case 9:
  switch (c)
{
case '"':
case '\\':
  f6 (x->c3, x->c1 + j, x->c2 - j - 1);
  j = x->c2++;
  a = b;
  break;
case 'b':
case 'n':
ca

[Bug tree-optimization/64878] [5 Regression] Miscompilation of nntpgrab

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-30
 CC||spop at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

[Bug tree-optimization/64878] [5 Regression] Miscompilation of nntpgrab

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/64867] warning for passing non-POD to varargs function

[tromey at gcc dot gnu.org]

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

--- Comment #9 from Tom Tromey  ---
> Are you sure that class is not trivial which is why gcc is not warning about
> it?  C++11 does not really have pod and non-pod any more but rather trivial
> and non-trivial and the rules has chnaged with respect of constructures.

I hesitate to say I'm sure :)

However my belief is that because this class has a user-provided
default constructor, it is not trivial.

I tested this by adding "#include " and then

static_assert(!std::is_trivial::value, "whoops");


Trivial or not, I'd like to get a warning here.  In firefox varargs
is really only used for printf-like things; but for various reasons
there are some custom implementations which can't be marked
with the "printf" attribute.  So while doing a refactoring it turned
out I inadvertently changed code to pass objects rather than char*
to one of these ... but finding the problem locations is proving
to be rather difficult.

[Bug target/64617] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) with -ftree-vectorize -mavx512bw -march=slm

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Jan 30 17:47:44 2015
New Revision: 220294

URL: https://gcc.gnu.org/viewcvs?rev=220294&root=gcc&view=rev
Log:
2015-01-30  Vladimir Makarov  

PR target/64617
* lra-constraints.c (prohibited_class_reg_set_mode_p): New
function.
(process_alt_operands): Use it.
(curr_insn_transform): Check the optional reload pseudo class is
ok for the mode.

2015-01-30  Vladimir Makarov  

PR target/64617
* gcc.target/i386/pr64617.c: New test.



Added:
trunk/gcc/testsuite/gcc.target/i386/pr64617.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/63923] FAIL: libgomp.c/examples-4/e.50.1.c (test for excess errors)

[iverbin at gcc dot gnu.org]

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

iverbin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from iverbin at gcc dot gnu.org ---
Fixed.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[hubicka at ucw dot cz]

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

--- Comment #15 from Jan Hubicka  ---
> No.  Each dso's gcov machinery is individually invoked.  There should be no
> cross-dso accessing of data (beyond the global chain of dso)
I am not saying my fix is correct, just lets me to continue in training
firefox.
So I have one global chain and one gcov destructor walking it.  What I think is
done is that the file is open by gcov-io copy of the global destructor, but
when
we merge profiles we indirectly call into merge function from other copy.

It should be easy to reproduce by profiling something consisting of two DSOs.

Honza

[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
make_forwarder_block is definitely wrong on not capping. But I do not see how
vectorizing can get us to a frequncy over FREQ_MAX? So probably some earlier
bug in there too

[Bug c++/64877] strange warning message from -Waddress

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Tom Tromey from comment #0)
> The message here is strange.  Whether or not the address can be NULL
> is not an issue.  I don't see why -Waddress ought to warn here at all.

Hard to say without a minimized testcase.

[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")

[dmalcolm at gcc dot gnu.org]

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

--- Comment #21 from David Malcolm  ---
*** Bug 64873 has been marked as a duplicate of this bug. ***

[Bug jit/64873] jit testsuite failures on powerpc64le-unknown-linux-gnu

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
(In reply to David Malcolm from comment #2)
> I'll rerun the JIT build and tests, with the correct configuration flags for
> this hardware, and  with the candidate patches for PR jit/64810 (so that the
> jit honors them).

Indeed, upon applying the candidate fixes for PR jit/64810 posted to:
  https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02704.html
and reconfiguring with:
  --with-cpu-64=power7 --with-tune-64=power8
the jit testsuite successfully runs to completion on this "box", with
everything passing (apart from known failure PR jit/64752); injected
options are visible in jit logs as:
configure_time_options[0]: -mtune=power8
configure_time_options[1]: -mcpu=power7

So this was a mixture of configuration error on my part, and a duplicate
of PR jit/64810.

Closing as a duplicate of PR jit/64810; sorry for the noise.

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

[Bug c++/64877] strange warning message from -Waddress

[tromey at gcc dot gnu.org]

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

--- Comment #2 from Tom Tromey  ---
(In reply to Manuel López-Ibáñez from comment #1)

> Hard to say without a minimized testcase.

Yeah.

The original code is here:

https://dxr.mozilla.org/mozilla-central/source/gfx/gl/ScopedGLHelpers.h#35

My attempt to minimize it failed.
Here's what I tried.  I can't explain why this doesn't 
give any warnings as I would expect one on the second "assert",
based on what the manual says.

template
struct S
{
  void m() {
  }

  S()
  {
if (&S::Unwrap != &Derived::Unwrap)
  m();
if (!(&Derived::UnwrapImpl))
  m();
  }

  void Unwrap() {
  }
};

struct T : public S
{
  void UnwrapImpl() {
  }
};

T t;

[Bug c++/64867] warning for passing non-POD to varargs function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
FYI, g++ stopped warning on #c4 with r149721.

[Bug c++/64877] strange warning message from -Waddress

[tromey at gcc dot gnu.org]

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

--- Comment #3 from Tom Tromey  ---
Oops, had the wrong gcc in $PATH.
That test case does warn:

pokyo. g++ -std=c++11 -c -Wall -Waddress -O2 x.cc
x.cc: In instantiation of ‘S::S() [with Derived = T]’:
x.cc:19:8:   required from here
x.cc:9:29: warning: the address of ‘void S::Unwrap() [with Derived =
T]’ will never be NULL [-Waddress]
 if (&S::Unwrap != &Derived::Unwrap)
 ^


I think I would expect a warning on the second assert, but not the first.

[Bug c++/64879] New: ICE for -O3 when calling a transactional method from a transaction inside a for loop

[bjmnbraun at gmail dot com]

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

Bug ID: 64879
   Summary: ICE for -O3 when calling a transactional method from a
transaction inside a for loop
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bjmnbraun at gmail dot com

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

The following code leads to ICE on g++-4.9.2 with -O3. Lower optimization modes
compile correctly.

test.cc:

int d;

void foo(){
__transaction_atomic {
d++;
}
}

int main() {
for(int i = 0; i < 2; i++){
__transaction_atomic {
foo();
}

std::vector myVec;
myVec.push_back(40);
}
}

the error output is

test.cc: In function ‘int main()’:
test.cc:33:5: internal compiler error: Segmentation fault
 int main() {

compiled with

g++ -v -std=c++11 -fgnu-tm -O3 -o test.out test.cc
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-0ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-0ubuntu1~14.04) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-fgnu-tm' '-O3' '-o' 'test.out'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-pthread'
 /usr/lib/gcc/x86_64-linux-gnu/4.9/cc1plus -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE -D_REENTRANT test.cc -quiet -dumpbase test.cc
-mtune=generic -march=x86-64 -auxbase test -O3 -std=c++11 -version -fgnu-tm
-fstack-protector -Wformat -Wformat-security -o /tmp/ccoWI5gH.s
GNU C++ (Ubuntu 4.9.2-0ubuntu1~14.04) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/4.9"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.9
 /usr/include/x86_64-linux-gnu/c++/4.9
 /usr/include/c++/4.9/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.9/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++ (Ubuntu 4.9.2-0ubuntu1~14.04) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bb3a956465d772c916e7b708c90318b2

[Bug libgomp/64880] New: OpenACC gcc/g++ Discrepancy

[tbatgcc at gmail dot com]

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

Bug ID: 64880
   Summary: OpenACC gcc/g++ Discrepancy
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tbatgcc at gmail dot com
CC: jakub at gcc dot gnu.org

Using revision 220245.

When trying to compile loop-1.c from trunk/gcc/testsuite/c-c++-common/goacc,
the last two errors generated by combined directives (e.g. #pragma acc parallel
loop, a shorthand for two directives) differ between the C and C++ compiler.

GCC output:
---

./gcc -c -fopenacc ../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c: In function
'test1':
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:11:3: error: for
statement expected before 'while'
   while(1)  /* { dg-error "for statement expected" } */
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:18:7: error:
expected iteration declaration or initialization before ';' token
   for(;;)  /* { dg-error "expected iteration declaration or initialization" }
*/
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:20:18: error: break
statement used with OpenMP for loop
   if (i > 0) break; /* { dg-error "break statement used" } */
  ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:25:3: error: for
statement expected before 'do'
   do  /* { dg-error "for statement expected" } */
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:31:3: error: for
statement expected before 'while'
   while (i < 8)  /* { dg-error "for statement expected" } */
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:36:12: error:
invalid type for iteration variable 'd'
   for (d = 1; d < 30; d+= 6)  /* { dg-error "invalid type for iteration
variable" } */
^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:43:18: error: break
statement used with OpenMP for loop
 if (i == 16) break; /* { dg-error "break statement used" } */
  ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:58:5: error: for
statement expected before 'a'
 a[1] = 1; /* { dg-error "for statement expected" } */
 ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:62:11: sorry,
unimplemented: directive not yet implemented
   #pragma acc parallel loop
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:66:11: sorry,
unimplemented: directive not yet implemented
   #pragma acc kernels loop
   ^



G++ output:
---

./g++ -c -fopenacc ../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c: In function 'int
test1()':
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:11:3: error: for
statement expected before 'while'
   while(1)  /* { dg-error "for statement expected" } */
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:20:18: error: break
statement used with OpenMP for loop
   if (i > 0) break; /* { dg-error "break statement used" } */
  ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:18:3: error:
expected iteration declaration or initialization
   for(;;)  /* { dg-error "expected iteration declaration or initialization" }
*/
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:25:3: error: for
statement expected before 'do'
   do  /* { dg-error "for statement expected" } */
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:31:3: error: for
statement expected before 'while'
   while (i < 8)  /* { dg-error "for statement expected" } */
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:36:3: error: invalid
type for iteration variable 'd'
   for (d = 1; d < 30; d+= 6)  /* { dg-error "invalid type for iteration
variable" } */
   ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:43:18: error: break
statement used with OpenMP for loop
 if (i == 16) break; /* { dg-error "break statement used" } */
  ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:58:5: error: for
statement expected before 'a'
 a[1] = 1; /* { dg-error "for statement expected" } */
 ^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:62:24: error:
expected '#pragma acc' clause before 'loop'
   #pragma acc parallel loop
^
../../gcc-master/gcc/testsuite/c-c++-common/goacc/loop-1.c:66:23: error:
expected '#pragma acc' clause before 'loop'
   #pragma acc kernels loop
   ^


As shown in this example, gcc produces a "sorry, unimplemented" error, whereas
g++ produces another type of error: "expected '#pragma acc' clause before
'loop'". This also happens by modifying the extension of the file to .cpp and
running gcc

[Bug c++/64879] ICE for -O3 when calling a transactional method from a transaction inside a for loop

[bjmnbraun at gmail dot com]

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

Benjamin Braun  changed:

   What|Removed |Added

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

--- Comment #1 from Benjamin Braun  ---
Whoops, I can reproduce this by replacing the for with a while loop. Going to
mark this as a duplicate of 63472 and add a comment on that bug.

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

[Bug c++/63472] transaction_atomic within while loop causes ICE

[bjmnbraun at gmail dot com]

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

Benjamin Braun  changed:

   What|Removed |Added

 CC||bjmnbraun at gmail dot com

--- Comment #5 from Benjamin Braun  ---
*** Bug 64879 has been marked as a duplicate of this bug. ***

[Bug target/64617] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) with -ftree-vectorize -mavx512bw -march=slm

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

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

[Bug rtl-optimization/64311] ICE: Max. number of generated reload insns per insn is achieved (90) with -fpic -march=corei7 for gcc.target/i386/avx512bw-vpbroadcast[bw]-1.c

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
This is duplicate of PR64617.

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

[Bug ada/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #14 from Dominique d'Humieres  ---
> Should be fixed, hopefully

Nope!-(

Yuta Tomino has posted a patch in comment 10 and I have taken the time to test
it (comment 11). Why are you taking so much time to commit non working commits?

[Bug target/64617] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) with -ftree-vectorize -mavx512bw -march=slm

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Should be fixed on trunk with Vlad's patch.

[Bug target/53949] [SH] Add support for mac.w / mac.l instructions

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-30
 Ever confirmed|0   |1

--- Comment #12 from Oleg Endo  ---
This is an example from Renesas public material regarding the SH-DSP.  The
example program can utilize either the regular mac.w instruction, or the DSP
ISA (found on SH2-DSP, SH3-DSP, SH4AL-DSP).

typedef short  Fixed;
typedef long Lfixed;
typedef long Laccum;
#define __X
#define __Y

void func(__X Fixed x[5],Fixed *out, __Y Fixed y[128][5] )
{
  int i;
  __Y Fixed *yp=y[0];
  __X Fixed *xp=x;
  Fixed x0,y0;
  Lfixed m0;
  Laccum a0;
  for(i=0;i<128;i++)
  {
a0=0;
x0=*xp++; y0=*yp++;
m0=x0*y0; x0=*xp++; y0=*yp++;
a0+=m0; m0=x0*y0; x0=*xp++; y0=*yp++;
a0+=m0; m0=x0*y0; x0=*xp++; y0=*yp++;
a0+=m0; m0=x0*y0; x0=*xp++; y0=*yp++;
a0+=m0; m0=x0*y0; 
a0+=m0;
*out++=a0;
  }
}

which should compile to something like:
_func:
mov #-128,r1
mov r5,r3
extu.b  r1,r1
.L11:
clrmac
mac.w   @r6+,@r4+
dt  r1
mac.w   @r6+,@r4+
mac.w   @r6+,@r4+
mac.w   @r6+,@r4+
sts macl,r2
mov.w   r2,@r3
bf/s.L11
add #2,r3

rts
nop

[Bug ipa/64872] [5 Regression] ICE: Segmentation fault during Chromium PGO build

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-30
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
This also happens during firefox non-PGO build.

[Bug c++/63472] transaction_atomic within while loop causes ICE

[torvald at gcc dot gnu.org]

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

--- Comment #6 from torvald at gcc dot gnu.org ---
(In reply to ak from comment #4)
> copy_bbs:
> 
> (illegal code due to goto into transaction?)
> 
> g_56[];
> fn1() {
>   int *p_79;
>   if (g_56[7])
> __transaction_atomic {
> lbl_196:
>   *p_79 = 1;
> }
>   else
> goto lbl_196;
> }

Yes, the goto into the transaction is illegal code.

> copy_loops:
> 
> func_65() {
>   __transaction_atomic {
> for (;;)
>   func_65();
>   }
> }

I think that technically, at least for C++, this is illegal code because you
have an infinite loop with no side effects (atomics, volatile, IO) in it.  Does
this also fail when you make the recursion stop eventually?

[Bug target/61599] [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2015-01-30
 CC||hjl.tools at gmail dot com
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #3 from Uroš Bizjak  ---
Adding -fpic, I got:

/ssd/uros/gcc-build/gcc/xgcc -B/ssd/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.target/i386/pr61599-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcmodel=medium
-fdata-sections
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.target/i386/pr61599-2.c -lm -fpic -o
./pr61599-1.exe
/tmp/ccfpoxHY.o: In function `bar':
pr61599-2.c:(.text+0xe): relocation truncated to fit: R_X86_64_PC32 against
symbol `a' defined in LARGE_COMMON section in /tmp/ccKTKST2.o
collect2: error: ld returned 1 exit status
compiler exited with status 1

Reopened, it looks that some sections are not handled correctly.

[Bug c++/63472] transaction_atomic within while loop causes ICE

[bjmnbraun at gmail dot com]

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

--- Comment #7 from Benjamin Braun  ---
A workaround for the code at the top of this thread is to wrap the transaction 
in the loop with a function and instead call that function from the loop.

This workaround also works for the case given in duplicate filing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64879, however the wrapper
function has to be marked __attribute__((noinline)) otherwise the function gets
inlined and then the workaround fails.

[Bug tree-optimization/64878] [5 Regression] Miscompilation of nntpgrab

[spop at gcc dot gnu.org]

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

--- Comment #1 from Sebastian Pop  ---
It fails with -O2 --param max-fsm-thread-paths=10 and does not fail with 9.
This is the thread that generates wrong code:
 Registering FSM jump thread: (102, 6) incoming edge;  (5, 128) nocopy;

[Bug tree-optimization/64878] [5 Regression] Miscompilation of nntpgrab

[spop at gcc dot gnu.org]

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

--- Comment #2 from Sebastian Pop  ---
Jump threading is called twice as two separate passes, the "miscompiled" jump
thread during the first invocation is:
 Registering FSM jump thread: (10, 114) incoming edge;  (4, 93) nocopy;

The "miscompiled" jump thread for the second invocation of dom is:

 Registering FSM jump thread: (102, 6) incoming edge;  (5, 128) nocopy;

[Bug tree-optimization/64878] [5 Regression] Miscompilation of nntpgrab

[spop at gcc dot gnu.org]

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

--- Comment #3 from Sebastian Pop  ---
-fdbg-cnt=registered_jump_thread:44 passes
-fdbg-cnt=registered_jump_thread:45 fails

So this is the jump thread that produces the wrong code:
 Registering FSM jump thread: (10, 114) incoming edge;  (4, 93) nocopy

[Bug sanitizer/64717] -fsanitize=vptr leads to warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized]

[gerrit.los at gmail dot com]

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

--- Comment #6 from Gert-jan Los  ---
I want to confirm that all false warnings in my code are fixed by your patch.

Thanks.

[Bug ipa/64872] [5 Regression] ICE: Segmentation fault during Chromium PGO build

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Created attachment 34630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34630&action=edit
Patch I am testing

The problem is that ICF merge profiles and profile merging sometimes nukes the
function body making it impossible to produce thunk later.

[Bug rtl-optimization/64688] [4.9/5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #13 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Jan 30 22:22:58 2015
New Revision: 220297

URL: https://gcc.gnu.org/viewcvs?rev=220297&root=gcc&view=rev
Log:
2015-01-30  Vladimir Makarov  

PR target/64688
* lra-constraints.c (original_subreg_reg_mode): New.
(simplify_operand_subreg): Try to simplify subreg of const.  Use
original_subreg_reg_mode for it.
(swap_operands): Update original_subreg_reg_mode.
(curr_insn_transform): Set up original_subreg_reg_mode.

2015-01-30  Vladimir Makarov  

PR target/64688
* g++.dg/pr64688-2.C: New.


Added:
trunk/gcc/testsuite/g++.dg/pr64688-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[xur at google dot com]

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

--- Comment #16 from xur at google dot com ---
I did not follow the trunk version closely. But from reading the code, I
think the design is each DSO uses its own copy of gcov_* functions
(including gcov_open and gcov_read_counter) and accesses its own gcov_var.
It seems to me that the global chain (by gcov_master) is merely used in
reset. The actually dump should be invoked by the gcov_exit registered for
each DSO (using its own __gcov_root) (i.e. there are multiple gcov_exit).

It's puzzling why firefox can be accessing NULL gcov_var. A reproducer
would be helpful.

-Rong


On Fri, Jan 30, 2015 at 10:02 AM, hubicka at ucw dot cz <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
>
> --- Comment #15 from Jan Hubicka  ---
> > No.  Each dso's gcov machinery is individually invoked.  There should be
> no
> > cross-dso accessing of data (beyond the global chain of dso)
> I am not saying my fix is correct, just lets me to continue in training
> firefox.
> So I have one global chain and one gcov destructor walking it.  What I
> think is
> done is that the file is open by gcov-io copy of the global destructor, but
> when
> we merge profiles we indirectly call into merge function from other copy.
>
> It should be easy to reproduce by profiling something consisting of two
> DSOs.
>
> Honza
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug libstdc++/64797] 22_locale/conversions/string/2.cc FAILs

[howarth at bromo dot med.uc.edu]

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

--- Comment #5 from howarth at bromo dot med.uc.edu ---
(In reply to Dominique d'Humieres from comment #4)
> The test has been introduced at r219780. The first failure I see is for
> r219808 (the previous tested revision is r219776). It is likely that the
> test has never worked on darwin.

Confirmed that 22_locale/conversions/string/2.cc fails at r219780 on
x86_64-apple-darwin14.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[nathan at acm dot org]

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

--- Comment #17 from Nathan Sidwell  ---
I'm having difficulty constructing a testcase that fails.  2 DSOs are isolated
as I expect.  (rong, your description is essentially correct).

A recipe would be good.  Also, is this on gcc trunk or gcc 5.0 branch (or
both?)

[Bug c++/64431] "-Wignored-qualifiers" warning gives misleading position in code

[eugene.zelenko at gmail dot com]

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

Eugene Zelenko  changed:

   What|Removed |Added

 CC||eugene.zelenko at gmail dot com

--- Comment #3 from Eugene Zelenko  ---
Same problem exists in 4.8.2 and 4.8.3 and probably earlier versions.

Will be good idea to fix problem there too.

Eugene.

[Bug rtl-optimization/64882] New: ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5681

[su at cs dot ucdavis.edu]

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

Bug ID: 64882
   Summary: ICE on valid code at -O3 with -g enabled in
simplify_subreg, at simplify-rtx.c:5681
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-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 with -g enabled on x86_64-linux-gnu in the 64-bit mode (but not in 32-bit
mode). 

This is a regression from 4.9.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/5.0.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 5.0.0 20150130 (experimental) [trunk revision 220273] (GCC) 
$ 
$ gcc-trunk -O3 -c small.c
$ gcc-trunk -O2 -g -c small.c
$ gcc-4.9 -O3 -g -c small.c
$ 
$ gcc-trunk -O3 -g -c small.c
small.c: In function ‘fn3’:
small.c:27:1: internal compiler error: in simplify_subreg, at
simplify-rtx.c:5681
 }
 ^
0xa6a4d5 simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)
../../gcc-trunk/gcc/simplify-rtx.c:5681
0xa6b359 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)
../../gcc-trunk/gcc/simplify-rtx.c:5901
0xd1cc07 vt_expand_loc_callback
../../gcc-trunk/gcc/var-tracking.c:8415
0x6fca51 cselib_expand_value_rtx_1
../../gcc-trunk/gcc/cselib.c:1669
0x6fde1e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-trunk/gcc/cselib.c:1551
0xd1ced5 vt_expand_var_loc_chain
../../gcc-trunk/gcc/var-tracking.c:8310
0xd1ced5 vt_expand_loc_callback
../../gcc-trunk/gcc/var-tracking.c:8472
0x6fcaf2 cselib_expand_value_rtx_1
../../gcc-trunk/gcc/cselib.c:1704
0x6fde1e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-trunk/gcc/cselib.c:1551
0xd1ced5 vt_expand_var_loc_chain
../../gcc-trunk/gcc/var-tracking.c:8310
0xd1ced5 vt_expand_loc_callback
../../gcc-trunk/gcc/var-tracking.c:8472
0x6fc90c cselib_expand_value_rtx_1
../../gcc-trunk/gcc/cselib.c:1742
0x6fde1e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-trunk/gcc/cselib.c:1551
0xd1ced5 vt_expand_var_loc_chain
../../gcc-trunk/gcc/var-tracking.c:8310
0xd1ced5 vt_expand_loc_callback
../../gcc-trunk/gcc/var-tracking.c:8472
0x6fcaf2 cselib_expand_value_rtx_1
../../gcc-trunk/gcc/cselib.c:1704
0x6fde1e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-trunk/gcc/cselib.c:1551
0xd1ced5 vt_expand_var_loc_chain
../../gcc-trunk/gcc/var-tracking.c:8310
0xd1ced5 vt_expand_loc_callback
../../gcc-trunk/gcc/var-tracking.c:8472
0x6fde1e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc-trunk/gcc/cselib.c:1551
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;
long b;
static long *c = &b;

void fn1 (short p) { }

long
fn2 (long p1, long p2)
{
  return (p1 && p1 > 26854775807 - p2) || p1 < -p2 ? p1 : p1 + p2;
}

void
fn3 ()
{
  long f;
  int g = 3;
  int *h = &a;
  for (e = 0; e < 2; e++)
{
  int *i = &g;
  if (!fn2 (*c, 7 < d % (*i)--))
f = fn2 ((*h <= 0) | b, 5278350700);
  *h = f;
  fn1 (*h);
}
}

[Bug go/64021] Empty struct vs libffi

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #9 from Ian Lance Taylor  ---
I think this is fixed, or worked around, by
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01286.html , which changes libgo
so that a Go empty struct (or empty array) is mapped to "struct { void }". 
This gets around the libffi requirement that a struct has a field without
increasing the actual size of the type.

[Bug go/64001] gccgo: crash on stack splitting

[ian at airs dot com]

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

--- Comment #5 from Ian Lance Taylor  ---
Just a note that I have not been able to reproduce this.  I ran the program
from comment #1 50 times with no failures.

[Bug c++/64875] -Winline does not report C++ methods

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I don't think this warning is very relevant to C++.

In C++ 'inline' is more useful for telling the compiler that the function may
be defined in mutiple translation units, and that is typically more important
than whether it is actually inlined or not.

[Bug go/63560] __go_set_defer_retaddr shouldn't be split by IPA split

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Was the patch in comment #1 ever committed?  I don't see it.

[Bug go/63493] libgo: write power64 version of reflect.MakeFunc

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
No longer needed.  Now all targets use libffi for reflect.MakeFunc.

[Bug c++/64867] warning for passing non-POD to varargs function

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Tom Tromey from comment #9)
> However my belief is that because this class has a user-provided
> default constructor, it is not trivial.

True, but ...

> I tested this by adding "#include " and then
> 
> static_assert(!std::is_trivial::value, "whoops");

That's the wrong thing to assert:

  Passing a potentially-evaluated argument of class type (Clause 9)
  having a non-trivial copy constructor, a non-trivial move constructor,
  or a non-trivial destructor, with no corresponding parameter, is
  conditionally-supported with implementation-defined semantics.

Your type has a trivial copy constructor and trivial move constructor and
trivial destructor, so passing it to a varargs function is well-defined.

Give it a non-trivial destructor and you get a warning:

cs.cc: In function ‘void m(const char*)’:
cs.cc:33:12: warning: passing objects of non-trivially-copyable type ‘class
ConstUTF8CharsZ’ through ‘...’ is conditionally supported
[-Wconditionally-supported]
   zzz(m, cu);
^

[Bug c++/64867] warning for passing non-POD to varargs function

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
N.B. trivially-copyable is not the same as trivial (and there are separate type
traits for testing those two properties).

[Bug rtl-optimization/64688] [4.9/5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #14 from Jeffrey A. Law  ---
Should be fixed by Vlad's trunk checkin.