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

[hubicka at ucw dot cz]

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

--- Comment #9 from Jan Hubicka  ---
> > This suggests that cloning of function Search and not inlining
> > NextMove is only part of the story.
> > 
> 
> I'm attaching output of my script that compares inlining decisions.
> "File 1" is wpa inlining dump file generated by r219862, "File 2" is
> wpa inlining dump generated by r219863 on source where Search was
> annotated as noclone.

Thanks. I suppose we need to oprofile resulting binary and see.
> 
> (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.

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.

Thanks!
Honza

[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-25
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #7 from Uroš Bizjak  ---
Patch at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01255.html

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

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #10 from Jan Hubicka  ---
Maritn, also note that at that time tere was bug in inliner fixed by:2015-03-20
 Jan Hubicka 

* ipa-inline.c (can_inline_edge_p): Short circuit if inline_failed  
already is final.   
(ipa_inline): Recompute inline_failed codes.
* cif-code.def (FUNCTION_NOT_OPTIMIZED, REDEFINED_EXTERN_INLINE,
USES_COMDAT_LOCAL, ATTRIBUTE_MISMATCH, UNREACHABLE): Declare as 
CIF_FINAL_ERROR.

so it would be useful to try if the regression still exists on trunk.  With the
patch our SPEC testers reports improvement
http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-ai-64/186_crafty_recent_big.png
While Igor reports even anoter regression on Intel based machine (and slightly
different flags)

[Bug c++/65457] ICE in libgfortran/ieee/ieee_arithmetic.F90

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #4 from Bernd Edlinger  ---
no longer happens with current snapshot.

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

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka  ---
The chkp stuff is IMO bit problematic. I was thinking about cutting the
optimization queue but was always hesitant to do so because of the cache
locality and other implications. I am not sure if that was considered with chkp
approach and if the split is really needed. Not something to track for GCC 5
though.

The slowdown
http://gcc.opensuse.org/c++bench-frescobaldi/tramp3d/split-build.html
is quite gradual, while the code size jump
http://gcc.opensuse.org/c++bench-frescobaldi/tramp3d/
happened at one point.  I looked once into the code size with Jakub and part of
that seems to be due to unwind info no longer using cfi directives at older
gases. Part is the new heuristics.

I am still hopping to understand better the code size part. To get performance
back we however probalby look for several little factors contributing to the
slowdown.

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

[hubicka at ucw dot cz]

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

--- Comment #17 from Jan Hubicka  ---
> > Even though the inline decisions does not seem to be changed considerably
> > (at least on tramp3d).
> 
> Yeah, clobbers don't account for anything for size/inline estimates
> (well, I hope so!).

Yep, they are ignored.
> 
> And yes, doing DSE early is quite an old idea...  we should revisit it
> next stage1.

I also run into it several time.  We should not forget this time ;)

Honza

[Bug target/61051] Duplicated instructions in both conditional branches

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

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

--- Comment #2 from Steven Bosscher  ---
This is code hoisting. That's not performed at -O2. Try -Os.

[Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
So fixed (tried both snippets in comment 3).

[Bug c/65471] type interpretation in _Generic

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2015-03-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Suspending until the DR is resolved.

[Bug c/65452] strcmp (foo, foo) could give a warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
Confirmed.

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

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Wed, 25 Mar 2015, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
> 
> --- Comment #17 from Jan Hubicka  ---
> > > Even though the inline decisions does not seem to be changed considerably
> > > (at least on tramp3d).
> > 
> > Yeah, clobbers don't account for anything for size/inline estimates
> > (well, I hope so!).
> 
> Yep, they are ignored.

Btw, and we indeed generate more clobbers with GCC 5:

> grep CLOBBER a/tramp3d-v4.ii.015t.ssa | wc -l
8937
> grep CLOBBER b/tramp3d-v4.ii.018t.ssa | wc -l
12636

which is odd as we now have new code that replaces clobbers with
SSA default defs...

> grep CLOBBER a/tramp3d-v4.ii.010t.eh | wc -l
13012
> grep CLOBBER b/tramp3d-v4.ii.010t.eh | wc -l
13012
> grep CLOBBER a/tramp3d-v4.ii.011t.cfg | wc -l
12827
> grep CLOBBER b/tramp3d-v4.ii.011t.cfg | wc -l
12827

so we manage to drop a lot of them during into-SSA with GCC 4.9 but
fail to do that with GCC 5.  Which would mean we write less vars
into SSA form(?)

> grep '_[0-9]* =' a/tramp3d-v4.ii.015t.ssa | wc -l
46055
> grep '_[0-9]*(D)' a/tramp3d-v4.ii.015t.ssa | wc -l
30839

vs.

> grep '_[0-9]* =' b/tramp3d-v4.ii.018t.ssa | wc -l
45543
> grep '_[0-9]*(D)' b/tramp3d-v4.ii.018t.ssa | wc -l
33782

eventually it might be that in 4.9 local_pure_const runs for a functions
callees before we fixup its CFG and write it into SSA form.  That might
cause a significant cleanup of EH before entering into-SSA for 4.9
(as callees might become nothrow).  At least that's now my theory.

I wonder if it makes sense to run local + IPA pure-const as we now
do "IPA into-SSA".  So sth like

Index: gcc/passes.def
===
--- gcc/passes.def  (revision 221633)
+++ gcc/passes.def  (working copy)
@@ -58,7 +58,9 @@ along with GCC; see the file COPYING3.
   NEXT_PASS (pass_build_ssa);
   NEXT_PASS (pass_ubsan);
   NEXT_PASS (pass_early_warn_uninitialized);
+ NEXT_PASS (pass_local_pure_const);
   POP_INSERT_PASSES ()
+  NEXT_PASS (pass_ipa_pure_const);

   NEXT_PASS (pass_chkp_instrumentation_passes);
   PUSH_INSERT_PASSES_WITHIN (pass_chkp_instrumentation_passes)

(which likely doesn't work exactly like that, of course).  Or
keep doing local_pure_const only and make sure to process
pass_build_ssa_passes in a proper order.  Of course the real
power of local-pure-const only arrives when done after local
optimizations...

But I'd say the compile-time effect is clearly going into-SSA
before cleaning up EH significantly.

> > And yes, doing DSE early is quite an old idea...  we should revisit it
> > next stage1.
> 
> I also run into it several time.  We should not forget this time ;)

;)

[Bug c/65452] strcmp (foo, foo) could give a warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.0

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
Summary|[C++11] GCC rejects |[5 Regression] [C++11] GCC
   |operator== with two |rejects operator== with two
   |distinct pointers as not|distinct pointers as not
   |constexpr   |constexpr

[Bug middle-end/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|ASSIGNED|RESOLVED
  Component|tree-optimization   |middle-end
 Resolution|--- |FIXED

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

[Bug middle-end/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Wed Mar 25 08:46:20 2015
New Revision: 221654

URL: https://gcc.gnu.org/viewcvs?rev=221654&root=gcc&view=rev
Log:
2015-03-25  Richard Biener  

PR middle-end/65519
* genmatch.c (expr::gen_transform): Re-write to avoid
using gimple_build.

* gnat.dg/specs/opt2.ads: New testcase.

Added:
trunk/gcc/testsuite/gnat.dg/specs/opt2.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/genmatch.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|[5.0 Regression]|[5 Regression]
   |gfc_conv_procedure_call |gfc_conv_procedure_call
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Started with r221621.

[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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #4 from Dominique d'Humieres  ---
> I'd also appreciate a short workaround.

  subroutine selector_init (selector, weight)
real :: s
integer :: n, i
logical, dimension(:), allocatable :: mask
integer, allocatable :: tmpi(:)
real, allocatable :: tmpr(:)
s = sum (weight)
allocate (mask (size (weight)), source = weight /= 0)
n = count (mask)
if (n > 0) then
allocate(tmpi(n),tmpr(n))
tmpi = pack ([(i, i = 1, size (weight))], mask)
tmpr = pack (weight / s, mask)
allocate (selector%map (n), source = tmpi)
allocate (selector%weight (n), source = tmpr)
else
   allocate (selector%map (1), source = 1)
   allocate (selector%weight (1), source = 0.)
end if
  end subroutine selector_init

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Yeah, it is r218462.

[Bug testsuite/63256] [5 regression] FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS succeeded" 0

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||ma...@linux-mips.org

--- Comment #5 from Segher Boessenkool  ---
*** Bug 62028 has been marked as a duplicate of this bug. ***

[Bug testsuite/62028] Power64/Linux: FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS succeeded" 0

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Dup of 63256, which has more info.

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

[Bug lto/65536] LTO line number information garbled

[marxin at gcc dot gnu.org]

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

--- Comment #28 from Martin Liška  ---
(In reply to Jan Hubicka from comment #26)
> Created attachment 35130 [details]
> linemap
> 
> this is a proof of concept patch that makes streamer in to collect locations
> into a "cache" and apply them in sorted order (looking up correct max_column
> hints) at the end of handling of a given section.  It also has facility to
> throw away locations of trees that are freed.
> while sorting at stream in time is not cool, it does not show top in the
> profiles
> and memory use of the cache is actually dominated by other stuff we read,
> so this seems to work quite well in practice. Main problem would be if
> someone
> copied/used the locator before cache is applied.
> 
> This helps to get all lines and most of carrets right on firefox. I killed my
> Chromium tree so can't test it there (Martin, perhaps you could try?)

Sure.

Unfortunately, there's still ICE, which is caused by a function body load that
happens in IPA ICF:


In function ‘Create’:
lto1: internal compiler error: Segmentation fault
0x9037df crash_signal
../../gcc/toplev.c:383
0xed909c new_linemap
../../libcpp/line-map.c:265
0xed9467 linemap_add(line_maps*, lc_reason, unsigned int, char const*, unsigned
int)
../../libcpp/line-map.c:314
0xed98d0 linemap_line_start(line_maps*, unsigned int, unsigned int)
../../libcpp/line-map.c:566
0xa8b190 unpack_ts_block_value_fields
../../gcc/tree-streamer-in.c:414
0xa8b190 streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*)
../../gcc/tree-streamer-in.c:538
0x80a791 lto_read_tree_1
../../gcc/lto-streamer-in.c:1197
0x80ab04 lto_read_tree
../../gcc/lto-streamer-in.c:1234
0x80ab04 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../gcc/lto-streamer-in.c:1353
0x80ae01 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*)
../../gcc/lto-streamer-in.c:1258
0x80ae64 lto_input_tree(lto_input_block*, data_in*)
../../gcc/lto-streamer-in.c:1368
0xe26ff1 input_gimple_stmt
../../gcc/gimple-streamer-in.c:186
0xe26ff1 input_bb(lto_input_block*, LTO_tags, data_in*, function*, int)
../../gcc/gimple-streamer-in.c:303
0x80c457 input_function
../../gcc/lto-streamer-in.c:992
0x80c457 lto_read_body_or_constructor
../../gcc/lto-streamer-in.c:1129
0x614d5d cgraph_node::get_untransformed_body()
../../gcc/cgraph.c:3225
0xe6e580 ipa_icf::sem_function::init()
../../gcc/ipa-icf.c:1167
0xe6b730 ipa_icf::sem_item_optimizer::parse_nonsingleton_classes()
../../gcc/ipa-icf.c:2617
0xe72b9a ipa_icf::sem_item_optimizer::execute()
../../gcc/ipa-icf.c:2419
0xe74386 ipa_icf_driver
../../gcc/ipa-icf.c:3304

I also attach ODR warnings before and after the patch.

Diff

> 
> I did not have much time today to test the patch.  It also saves quite a lot
> of
> memory, about 400MB on firefox I guess.
> 
> Honza

[Bug lto/65536] LTO line number information garbled

[marxin at gcc dot gnu.org]

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

--- Comment #30 from Martin Liška  ---
Created attachment 35132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35132&action=edit
Chrome: ODR warnings with patch from #c21

[Bug lto/65536] LTO line number information garbled

[marxin at gcc dot gnu.org]

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

--- Comment #29 from Martin Liška  ---
Created attachment 35131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35131&action=edit
Chrome: ODR warnings before

[Bug tree-optimization/64715] [5 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

--- Comment #19 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #14)
> Or, as discussed on IRC we can consider MEM_REFs where first operand isn't
> just
> SSA_NAME or ADDR_EXPR of a decl, but allow also ADDR_EXPR of
> handled_component_p (with base being a decl or MEM_REF with SSA_NAME first
> operand).
> 
> Or add a new tree code, like OFFSETTED_ADDR_EXPR which would be like
> ADDR_EXPR, but with integer offset address to the ADDR_EXPR.

Thinking about this some more we already have the ability to combine

 _2 = &a.b[i].c;
 _3 = _2 + 8;

by using handled-components:

  &ARRAY_REF , 8 /
__sizeof__(a.b[i].c)>

that is, we could attack this by implementing pointer arithmetic as represented
by the frontend in the way it is defined by the C standard (in terms of array
indexing).

  ptr + idx

would be lowered as

  &ARRAY_REF , idx>

thereby also avoiding the need to apply promotion of idx to sizetype to
avoid the possible overflow of the multiplication by sizeof (*ptr).

Of course it would be nice to avoid the "awkward" VIEW_CONVERT_EXPR here,
but adding a new kind of handled-component isn't exactly non-intrusive either.

Btw, there is an alternative to the array-ref/view-convert-expr form that
is less restrictive on the actual 'idx'.  We could simply use

  COMPONENT_REF <*ptr, , explicit-offset>

though the fact that COMPONENT_REFs have alias analysis effects and that
the lowered offset is measured in DECL_OFFSET_ALIGN units of the field-decl
makes that non-trivial to support as well.

That said, the alternative is to add a new handled-component, say,
OFFSET_VIEW_CONVERT_EXPR , that would have the
same effect as doing

  _ptr = &base + offset;
  MEM [_ptr, offset];

thus offset carries type-based alias information and 'type' carries
alignment info.  Type-based alias analysis would stop at
OFFSET_VIEW_CONVERT_EXPR as it stops now at VIEW_CONVERT_EXPRs.

Now we could also simply change VIEW_CONVERT_EXPR to take an (optional?)
offset parameter.

I like all of the above choices more than special-casing an address-only
variant for offsets.  All of the above enable us to avoid making
variable-indexed indirect references addressable like we have to do now
because of the restrictions of MEM_REF bases / offsets.  The ARRAY_REF
variant allows to handle non-constant pointer offsets as well while
the offsetted VIEW_CONVERT_EXPR would handle only constant offsets
(but allow non-"element"-size increments and arbitrary effective alias
sets on the memory reference).

We should already handle the ARRAY_REF  ...> form
correctly today, we just don't create it.

[Bug lto/65536] LTO line number information garbled

[marxin at gcc dot gnu.org]

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

--- Comment #31 from Martin Liška  ---
Beginning of the difference of ODR warnings:

210,211c210,211
< gen/blink/core/CSSPropertyNames.cpp:2330:0: warning: type ‘struct
stringpool_t’ violates one definition rule [-Wodr]
<  static const short lookup[] =
---
> gen/blink/core/CSSPropertyNames.cpp:1019:0: warning: type ‘struct 
> stringpool_t’ violates one definition rule [-Wodr]
>  struct stringpool_t
213,214c213,214
< gen/blink/core/CSSValueKeywords.cpp:4309:0: note: a different type is defined
in another translation unit
 gen/blink/core/CSSValueKeywords.cpp:1850:0: note: a different type is defined 
> in another translation unit
>  struct stringpool_t
216,217c216,217
< gen/blink/core/CSSPropertyNames.cpp:2330:0: note: the first difference of
corresponding definitions is field ‘stringpool_str0’
<  static const short lookup[] =
---
> gen/blink/core/CSSPropertyNames.cpp:1021:0: note: the first difference of 
> corresponding definitions is field ‘stringpool_str0’
>  char stringpool_str0[sizeof("grid")];
219,220c219,220
< gen/blink/core/CSSValueKeywords.cpp:4309:0: note: a field of same name but
different type is defined in another translation unit
 gen/blink/core/CSSValueKeywords.cpp:1852:0: note: a field of same name but 
> different type is defined in another translation unit
>  char stringpool_str0[sizeof("dot")];
230,232c230,232
< ../../../../out/Release/gen/blink/core/XPathGrammar.cpp:241:0: note: a
different type is defined in another translation unit
< ../../../../out/Release/gen/blink/core/CSSGrammar.cpp:557:0: note: the first
difference of corresponding definitions is field ‘yyvs_alloc’
< ../../../../out/Release/gen/blink/core/XPathGrammar.cpp:241:0: note: a field
of same name but different type is defined in another translation unit
---
> ../../../../out/Release/gen/blink/core/XPathGrammar.cpp:373:0: note: a 
> different type is defined in another translation unit
> ../../../../out/Release/gen/blink/core/CSSGrammar.cpp:560:0: note: the first 
> difference of corresponding definitions is field ‘yyvs_alloc’
> ../../../../out/Release/gen/blink/core/XPathGrammar.cpp:376:0: note: a field 
> of same name but different type is defined in another translation unit


...

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from vehre at gcc dot gnu.org ---
The function call is processed w/o a scalarizer, which is quite errorprone. I
already have a fix. Now I just have get the other functionality of gfortran
back online.

[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from vehre at gcc dot gnu.org ---
Fixed with commit r221621.

[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from vehre at gcc dot gnu.org ---
Fixed with commit r221627.

[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Fixed with commit r221621.

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
The difference between when i1 and i2 are constexprs and when they are not is
that their cgraph nodes have definition = false if they are constexprs.
Dunno if that is intentional or not.

[Bug lto/65536] LTO line number information garbled

[rguenth at gcc dot gnu.org]

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

--- Comment #32 from Richard Biener  ---
(In reply to Jan Hubicka from comment #16)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
> > 
> > --- Comment #2 from Richard Biener  ---
> > The main issue with LTO is that it re-creates a combined linemap but in 
> > (most
> > of the time) quite awkward ordering (simply registering random-ordered
> > file:line:column entries by switching files/lines "appropriately").
> > 
> > I've argued that it would be better to stream those file:line:columns
> > separately so we can "sort" them before handing them over to libcpp for
> > linemap re-creation.
> 
> Yep, we discussed this few times.  One issue is when we sort them. 
> We can keep track of location as they are streamed out (and directly assign
> them new IDs in the awkward ordering as they come) and then produce the
> separate linemap section that would be read at once by WPA, sorted and
> fed into linemaps.
> 
> Sorting at compile time is bit tricky as we probably do not want to patch
> existing pickled tree stream with the new locator IDs in the sorted sequence
> and we do not really know what locations we will need ahead of time.

Well, the idea was to stream another index representing the sorted order
so we can sort and merge at WPA in O(n) and re-map the index on stream-in
time.  I don't think we want to sort at WPA time.

> Other easier to implement idea for GCC 5 may be to simply collect locaiton
> info and pointers to trees per SCC component andonly if it survived merging
> feed it into linemap and in memory patch the new trees. This still should
> save quite some memory given that most of trees read are discarded by merging
> and may be quite easy to implement.
> 
> Martin, the ICE by my patch is caused by libcpp getting out of memory?

Btw, we don't have to fix this for GCC 5.  We can of course backport a
good solution later.

[Bug libstdc++/65543] rvalue stream insertion and extraction operators incorrectly implemented

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Mar 25 09:57:06 2015
New Revision: 221655

URL: https://gcc.gnu.org/viewcvs?rev=221655&root=gcc&view=rev
Log:
2015-03-25  Paolo Carlini  

PR libstdc++/65543
* include/std/istream (operator>>(basic_istream<>&&, _Tp&): Revert
thinko in r150387.
* include/std/ostream (operator<<(basic_ostream<>&&, const _Tp&):
Likewise.
* testsuite/27_io/rvalue_streams-2.cc: New.

Added:
trunk/libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/istream
trunk/libstdc++-v3/include/std/ostream

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 25 09:58:18 2015
New Revision: 221656

URL: https://gcc.gnu.org/viewcvs?rev=221656&root=gcc&view=rev
Log:
PR lto/65515
* lto-streamer-out.c (DFS::worklist): New struct.
(DFS::worklist_vec): New data member.
(DFS::next_dfs_num): Remove.
(DFS::DFS): Rewritten using worklist instead of recursion,
using most of code from DFS::DFS_write_tree.
(DFS::DFS_write_tree_body): Remove SINGLE_P argument, don't
pass it to DFS_write_tree calls.
(DFS::DFS_write_tree): Remove SINGLE_P argument, after
quick initial checks push it into worklist_vec and return.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c

[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug lto/65536] LTO line number information garbled

[rguenth at gcc dot gnu.org]

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

--- Comment #33 from Richard Biener  ---
(In reply to Jan Hubicka from comment #26)
> Created attachment 35130 [details]
> linemap
> 
> this is a proof of concept patch that makes streamer in to collect locations
> into a "cache" and apply them in sorted order (looking up correct max_column
> hints) at the end of handling of a given section.  It also has facility to
> throw away locations of trees that are freed.
> while sorting at stream in time is not cool, it does not show top in the
> profiles
> and memory use of the cache is actually dominated by other stuff we read,
> so this seems to work quite well in practice. Main problem would be if
> someone
> copied/used the locator before cache is applied.
> 
> This helps to get all lines and most of carrets right on firefox. I killed my
> Chromium tree so can't test it there (Martin, perhaps you could try?)
> 
> I did not have much time today to test the patch.  It also saves quite a lot
> of
> memory, about 400MB on firefox I guess.

Looks sensible to me (apart from sorting at WPA time and missing TLC like
adding function/code comments and removing no-op hunks).

Richard.

> Honza

[Bug lto/65544] LTO link fails with -static-libstdc++ + weak new/delete operators

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Can you verify if the cross compiler uses a linker-plugin by specifying
-fuse-linker-plugin?  Without that errors like this are unfortunately expected.

[Bug target/65546] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Peeling is certainly not profitable as with just 32 char elements in tmp.b
and then just iterating over the first 16 there will be no vectorized
iteration left if we peel at least one iteration (assuming v16qi vectors).
Possibly 4.9 catched this only with the cost model (for targets that support
unaligned stores aligned ones may be still better but of course in this
case peeling for alignment should be forcefully disabled as it doesn't make
sense and just makes us not consider using an unaligned store).

Thus, testsuite issue I think.

[Bug fortran/65532] [5 Regression] Unexpected error with legacy code (D1MACH)

[mikael at gcc dot gnu.org]

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

--- Comment #7 from Mikael Morin  ---
Author: mikael
Date: Wed Mar 25 10:15:46 2015
New Revision: 221657

URL: https://gcc.gnu.org/viewcvs?rev=221657&root=gcc&view=rev
Log:
Fix regression introduced at revision 221586.

PR fortran/64952
PR fortran/65532
fortran/
* gfortran.h (struct gfc_namespace): New field 'types_resolved'.
* resolve.c (resolve_types): Return early if field 'types_resolved'
is set.  Set 'types_resolved' at the end.
testsuite/
* gfortran.dg/data_initialized_3.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/data_initialized_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/64952] Missing temporary in assignment from elemental function

[mikael at gcc dot gnu.org]

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

--- Comment #11 from Mikael Morin  ---
Author: mikael
Date: Wed Mar 25 10:15:46 2015
New Revision: 221657

URL: https://gcc.gnu.org/viewcvs?rev=221657&root=gcc&view=rev
Log:
Fix regression introduced at revision 221586.

PR fortran/64952
PR fortran/65532
fortran/
* gfortran.h (struct gfc_namespace): New field 'types_resolved'.
* resolve.c (resolve_types): Return early if field 'types_resolved'
is set.  Set 'types_resolved' at the end.
testsuite/
* gfortran.dg/data_initialized_3.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/data_initialized_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/62164] 5.0: ICE: error: Both section and comdat group is set

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
This seems to be fixed now.

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
const int i1 = 1;
const int i2 = 2;
constexpr auto b = &i1 == &i2;
int main() {}

is now also rejected, when it used to be accepted.

[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Edward Diener from comment #0)
> Instead gcc outputs the warning:
> 
> "warning: ISO C99 requires rest arguments to be used".
> 
> But since the compile is done with C++11 support the reference should be to
> the C++11 standard

Already fixed for GCC 5.

v.c:2:21: warning: ISO C++11 requires at least one argument for the "..." in a
variadic macro


> and an error should occur. That an error does not occur I
> consider a bug.

No, the standard doesn't require an error, it requires a diagnostic message.

"If a program contains a violation of any diagnosable rule or an occurrence of
a construct described in this Standard as “conditionally-supported” when the
implementation does not support that construct, a conforming implementation
shall issue at least one diagnostic message."

A warning is a diagnostic message, ergo there is no bug.

As Andrew pointed out, use -pedantic-errors (or -Werror=pedantic) if you want
to turn such warnings into errors.

[Bug debug/65549] New: crash in htab_hash_string with -flto

[a...@cloudius-systems.com]

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

Bug ID: 65549
   Summary: crash in htab_hash_string with -flto
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com

lto1: internal compiler error: Segmentation fault
0xa283bf crash_signal
../../gcc/toplev.c:383
0x111c7b0 htab_hash_string
../../libiberty/hashtab.c:839
0x6d06bf external_ref_hasher::hash(external_ref const*)
../../gcc/dwarf2out.c:7763
0x6d06bf hash_table::find_slot(external_ref const*, insert_option)
../../gcc/hash-table.h:652
0x6d06bf lookup_external_ref
../../gcc/dwarf2out.c:7791
0x6d075d optimize_external_refs_1
../../gcc/dwarf2out.c:7829
0x6d0788 optimize_external_refs_1
../../gcc/dwarf2out.c:7833
0x6d0bc6 optimize_external_refs
../../gcc/dwarf2out.c:7882
0x6d0dfd output_comp_unit
../../gcc/dwarf2out.c:9122
0x6f6cd9 dwarf2out_finish
../../gcc/dwarf2out.c:24800
Please submit a full bug report,

g++5 (GCC) 5.0.0 20150324 (experimental)

To reproduce, clone seastar (https://github.com/cloudius-systems/seastar)

  ./configure.py --compiler /path/to/g++5 --cflags='-flto
-D_GLIBCXX_USE_CXX11_ABI=0'
  ninja build/release/tests/tcp_client   # named ninja-build on Fedora)

[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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC||trippels at gcc dot gnu.org
Summary|crash in htab_hash_string   |[5 Regression] crash in
   |with -flto  |htab_hash_string with -flto
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. Reducing...

[Bug c++/61670] ICE on invalid in tree_nop_conversion

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Testing a fix.

[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro

[eldlistmailingz at tropicsoft dot com]

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

--- Comment #3 from Edward Diener  ---
Where do you get the idea that the standard doesn't require an error, it
requires a diagnostic message ?

It clearly is a violation of the C++11 standard according to the section and
paragraph I cited in my bug report.

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler  ---
(In reply to Jakub Jelinek from comment #5)
> const int i1 = 1;
> const int i2 = 2;
> constexpr auto b = &i1 == &i2;
> int main() {}
> 
> is now also rejected, when it used to be accepted.

Both behavioral changes look incorrect to me. The addresses of such global
objects are valid for equality comparison irrespective whether they are
constexpr or not, because == has no pre-condition:

"Two pointers compare equal if they are both null, both point to the same
function, or both represent the same address (3.9.2), otherwise they compare
unequal."

therefore we cannot fall into the exclusion bullet within 5.20 p2

"a relational (5.9) or equality (5.10) operator where the result is
unspecified;"

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug tree-optimization/65538] [5 Regression] Memory leak of ipa_node_params_sum elements

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Wed Mar 25 11:47:04 2015
New Revision: 221658

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

PR tree-optimization/65538
* symbol-summary.h (function_summary::~function_summary):
Relese memory for allocated summaries.
(function_summary::release): New function.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/symbol-summary.h

[Bug tree-optimization/65538] [5 Regression] Memory leak of ipa_node_params_sum elements

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed in 5.0.0.

[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Edward Diener from comment #3)
> Where do you get the idea that the standard doesn't require an error, it
> requires a diagnostic message ?

1.4 [intro.compliance], the text I quoted. Where do you get the idea it
requires an error?

[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
And as has been documented forever, the way to get diagnostics for GNU
extensions that contradict the ISO standard is the -pedantic switch:

https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Warning-Options.html#index-pedantic-279

There is no bug here.

[Bug target/65508] ICE: in initialize_inlined_parameters, at tree-inline.c:3305 with -fcheck-pointer-bounds -mmpx and nested function

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from ienkovich at gcc dot gnu.org ---
Author: ienkovich
Date: Wed Mar 25 12:41:27 2015
New Revision: 221661

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

PR target/65508
* tree-chkp.c (chkp_add_bounds_to_call_stmt): Set static
chain for generated call.

gcc/testsuite/

PR target/65508
* gcc.target/i386/mpx/pr65508.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/mpx/pr65508.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c

[Bug target/65508] ICE: in initialize_inlined_parameters, at tree-inline.c:3305 with -fcheck-pointer-bounds -mmpx and nested function

[ienkovich at gcc dot gnu.org]

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

ienkovich at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ienkovich at gcc dot gnu.org ---
Fixed

[Bug tree-optimization/62630] [5/6 Regression] gcc.dg/graphite/vect-pr43423.c XFAILed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||xfail
  Known to work||4.9.2
   Target Milestone|5.0 |6.0
Summary|[5 regression]  |[5/6 Regression]
   |gcc.dg/graphite/vect-pr4342 |gcc.dg/graphite/vect-pr4342
   |3.c FAILs   |3.c XFAILed
  Known to fail||5.0

--- Comment #20 from Richard Biener  ---
XFAILed.

[Bug tree-optimization/62630] [5/6 Regression] gcc.dg/graphite/vect-pr43423.c XFAILed

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
Author: rguenth
Date: Wed Mar 25 12:54:12 2015
New Revision: 221662

URL: https://gcc.gnu.org/viewcvs?rev=221662&root=gcc&view=rev
Log:
2015-03-25  Richard Biener  

PR tree-optimization/62630
* gcc.dg/graphite/vect-pr43423.c: XFAIL.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c

[Bug libstdc++/65543] rvalue stream insertion and extraction operators incorrectly implemented

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Mar 25 12:55:04 2015
New Revision: 221663

URL: https://gcc.gnu.org/viewcvs?rev=221663&root=gcc&view=rev
Log:
2015-03-25  Paolo Carlini  

PR libstdc++/65543
* include/std/istream (operator>>(basic_istream<>&&, _Tp&): Revert
thinko in r150387.
* include/std/ostream (operator<<(basic_ostream<>&&, const _Tp&):
Likewise.
* testsuite/27_io/rvalue_streams-2.cc: New.

Added:
branches/gcc-4_9-branch/libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/std/istream
branches/gcc-4_9-branch/libstdc++-v3/include/std/ostream

[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P1

[Bug libstdc++/65543] rvalue stream insertion and extraction operators incorrectly implemented

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Mar 25 12:55:22 2015
New Revision: 221664

URL: https://gcc.gnu.org/viewcvs?rev=221664&root=gcc&view=rev
Log:
2015-03-25  Paolo Carlini  

PR libstdc++/65543
* include/std/istream (operator>>(basic_istream<>&&, _Tp&): Revert
thinko in r150387.
* include/std/ostream (operator<<(basic_ostream<>&&, const _Tp&):
Likewise.
* testsuite/27_io/rvalue_streams-2.cc: New.

Added:
branches/gcc-4_8-branch/libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc
Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/include/std/istream
branches/gcc-4_8-branch/libstdc++-v3/include/std/ostream

[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 #34 from Manuel López-Ibáñez  ---
(In reply to Martin Liška from comment #30)
> Created attachment 35132 [details]
> Chrome: ODR warnings with patch from #c21

@Martin:

The previous comment where the ICE is mentioned seems to refer to Jan's latest
patch (with the cache), but this comment appears to refer to my patch in
comment 21. Is that right? 

I don't see how you can get that backtrace with Jan's patch: linemap_line_start
should only be called when applying the location cache, no?

@Jan:
I think:

+  linemap_line_start (line_table, loc.line,
+  MAX (81, loc.col + 1))

should simply be:

+  linemap_line_start (line_table, loc.line,
+  max + 1)


For what is worth, I think your patch should already help a lot in GCC 5, it
seems a move in the right direction. Perhaps the WPA sorting time is offset by
the memory savings and lower number of maps, which should reduce lookup times.

It would really be interesting to compute the sum of
dump_line_table_statistics() for each input file before stream out and for the
LTO line_table after stream in. It will give you some idea of how much you can
expect to save in streamed out data and LTO memory by streaming out the
line_tables directly.

[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 #19 from Richard Biener  ---
I've meanwhile disabled pass_chkp_instrumentation_passes by default.

The fixup_cfg in pass_build_ssa_passes doesn't do anything on tramp3d
(and bootstrap/testing shows no issue removing it either).

Adding a local_pure_const to the end of build_ssa_passes unfortunately
makes us ICE in cgraph node verification during early inlining (we have
a dangling call-stmt without a BB on a cgraph edge).  Not sure how that
happens as we fixup the cfg and rebuild cgraph edges before early inlining.
Looks like re-building cgraph edges fixes that.

This brings down the number of clobbers and stmts to 4.9 level.

Index: gcc/passes.def
===
--- gcc/passes.def  (revision 221660)
+++ gcc/passes.def  (working copy)
@@ -54,10 +54,12 @@ along with GCC; see the file COPYING3.
   NEXT_PASS (pass_build_ssa_passes);
   PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes)
   NEXT_PASS (pass_fixup_cfg);
+  NEXT_PASS (pass_rebuild_cgraph_edges);
   NEXT_PASS (pass_init_datastructures);
   NEXT_PASS (pass_build_ssa);
   NEXT_PASS (pass_ubsan);
   NEXT_PASS (pass_early_warn_uninitialized);
+  NEXT_PASS (pass_local_pure_const);
   POP_INSERT_PASSES ()

   NEXT_PASS (pass_chkp_instrumentation_passes);

as opposed to the also possible patch (which doesn't change anything but
compile-time):

Index: gcc/passes.def
===
--- gcc/passes.def  (revision 221657)
+++ gcc/passes.def  (working copy)
@@ -53,7 +53,6 @@ along with GCC; see the file COPYING3.
   NEXT_PASS (pass_ipa_chkp_early_produce_thunks);
   NEXT_PASS (pass_build_ssa_passes);
   PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes)
-  NEXT_PASS (pass_fixup_cfg);
   NEXT_PASS (pass_init_datastructures);
   NEXT_PASS (pass_build_ssa);
   NEXT_PASS (pass_ubsan);

[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple "memcpy"

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org

--- Comment #8 from alalaw01 at gcc dot gnu.org ---
This test was also failing for target arm-none-eabi, also fixed by Jakub's
r221607.

[Bug fortran/65541] [5 Regression] namelist regression

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> This fixes it: ...

Confimed (the patch in comment 4 does not apply cleanly and needs some minor
surgery) and it regtest without regression.

Thanks for quick fix.

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.5
Summary|ICE with {} initialized |[4.8/4.9/5 Regression] ICE
   |array with string   |with {} initialized array
   ||with string

--- Comment #3 from Marek Polacek  ---
4.6 didn't ICE, thus a regression.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
Results with the patch in comment 11 at

https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg02484.html

Note that the patch in comment 6 also fixes this PR. It is probably the best
short term solution. Could it be committed for 5.1?

[Bug c++/65415] using, base class static member function template, and decltype

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Trunk accepts the code since r221478.

[Bug libstdc++/65543] rvalue stream insertion and extraction operators incorrectly implemented

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.0 |4.8.5

--- Comment #6 from Paolo Carlini  ---
Fixed for 5.0, 4.9.3, 4.8.5.

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

[jakub at gcc dot gnu.org]

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

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

Untested temporary hack for GCC 5.

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #4)
> The difference between when i1 and i2 are constexprs and when they are not
> is that their cgraph nodes have definition = false if they are constexprs.
> Dunno if that is intentional or not.

True, they don't have definitions because we're trying to evaluate the
constexpr comparison in cxx_eval_binary_expression before finalize_decl could
create the definitions for i1 and i2.

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Most likely started with r175674.

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

[doko at gcc dot gnu.org]

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

Bug ID: 65550
   Summary: [5 Regression] ICE (segfault) with pch
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

seen building the mp4v2 package in Debian unstable with r221551 and pch
enabled. disabling pch lets the package build succeed.

Program received signal SIGABRT, Aborted.
0x7690a107 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x7690a107 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7690b4e8 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0136f69a in linemap_add(line_maps*, lc_reason, unsigned int, char
const*, unsigned int) ()
#3  0x0136f913 in linemap_line_start(line_maps*, unsigned int, unsigned
int) ()
#4  0x0136fae1 in linemap_position_for_column(line_maps*, unsigned int)
()
#5  0x0136dbc2 in _cpp_lex_direct ()
#6  0x0136eaee in _cpp_lex_token ()
#7  0x01373a98 in cpp_get_token_1(cpp_reader*, unsigned int*) ()
#8  0x008760ed in c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) ()
#9  0x00715a50 in cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*)
()
#10 0x0074c9df in c_parse_file() ()
#11 0x0087e673 in c_common_parse_file() ()
#12 0x00cc2662 in compile_file() ()
#13 0x00611a3d in toplev::main(int, char**) ()
#14 0x006128fa in main ()

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
The following (untested) should work:

--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6113,6 +6113,7 @@ make_rtl_for_nonlocal_decl (tree decl, tree init, const
char* asmspec)
  not emitted into the object file unnecessarily.  */
   filename = LOCATION_FILE (input_location);
   if (!DECL_VIRTUAL_P (decl)
+  && !DECL_DECLARED_CONSTEXPR_P (decl)
   && TREE_READONLY (decl)
   && DECL_INITIAL (decl) != NULL_TREE
   && DECL_INITIAL (decl) != error_mark_node

My reasoning is that we shouldn't defer assembling the variable if it might be
needed in the constexpr context.

[Bug tree-optimization/65551] New: [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 65551
   Summary: [5 Regression]  FAIL: 26_numerics/complex/50880.cc
execution test
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: thopre01 at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
  Host: arm-none-linux-gnueabihf
Target: arm-none-linux-gnueabihf

As of r220390 we've started to FAIL this test from libstdc++ on
arm-none-linux-gnueabihf:

FAIL: 26_numerics/complex/50880.cc execution test
./50880.exe
50880.exe:
/work/jamgre01/gcc-src/libstdc++-v3/testsuite/26_numerics/complex/50880.cc:36:
void test01_do() [with T = double]: Assertion `cra.real() > T(0)' failed.
Aborted

Bisect pinpointed the failure to this commit:

Author: thopre01 
Date:   Wed Feb 4 08:22:45 2015 +

2015-02-04  Thomas Preud'homme  

gcc/
PR middle-end/62103
* tree-ssa-sccvn.c (fully_constant_vn_reference_p): Use TYPE_PRECISION
to compute size of referenced value in the constant case.

gcc/testsuite/
PR middle-end/62103
* gcc.c-torture/execute/bitfld-7.c: New test adapted from bitfld-6.c
to use 24 bits for bitfield b.

Compiler configured with: /work/jamgre01//gcc-src/configure
--with-cpu=cortex-a9 --with-fpu=neon-fp16 --with-mode=thumb --with-float=hard
--enable-languages=c,c++,fortran --prefix=/work/jamgre01//gcc-install
--with-build-config=bootstrap-time

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #8)
> The following (untested) should work:
> 
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -6113,6 +6113,7 @@ make_rtl_for_nonlocal_decl (tree decl, tree init,
> const char* asmspec)
>   not emitted into the object file unnecessarily.  */
>filename = LOCATION_FILE (input_location);
>if (!DECL_VIRTUAL_P (decl)
> +  && !DECL_DECLARED_CONSTEXPR_P (decl)
>&& TREE_READONLY (decl)
>&& DECL_INITIAL (decl) != NULL_TREE
>&& DECL_INITIAL (decl) != error_mark_node
> 
> My reasoning is that we shouldn't defer assembling the variable if it might
> be needed in the constexpr context.

But in the #c5 testcase it isn't DECL_DECLARED_CONSTEXPR_P, is it?

[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #9)
> But in the #c5 testcase it isn't DECL_DECLARED_CONSTEXPR_P, is it?

True :(.

[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string

[maltsevm at gmail dot com]

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

--- Comment #5 from Mikhail Maltsev  ---
I have posted a patch for this bug:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00026.html
But it reveals some latent bug (PR65503). In the following case (after applying
the patch):

struct ss {
ss() {};
};
struct C {
  ss s[1000];
};
int main() {
  C cs[5]{};
}

We'll get 1000 calls to ss() in main instead of calling default c-tor of struct
C. (which is probably not what we want).

[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

[ktietz at gcc dot gnu.org]

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

--- Comment #17 from Kai Tietz  ---
Author: ktietz
Date: Wed Mar 25 15:05:02 2015
New Revision: 221665

URL: https://gcc.gnu.org/viewcvs?rev=221665&root=gcc&view=rev
Log:
PR libgomp/64972
* oacc-parallel.c (GOACC_parallel): Use PRIu64 if available.
(GOACC_data_start): Likewise.
* target.c (gomp_map_vars): Likewise.


Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-parallel.c
trunk/libgomp/target.c

[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #18 from Kai Tietz  ---
Fixed on trunk.

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Doesn't happen with --enable-checking=release.

src/bmff/impl.h:126:5: internal compiler error: Aborted
0xcaf40f crash_signal
../../gcc/gcc/toplev.c:383
0x1339c09 linemap_add(line_maps*, lc_reason, unsigned int, char const*,
unsigned int)
../../gcc/libcpp/line-map.c:297
0x1339e82 linemap_line_start(line_maps*, unsigned int, unsigned int)
../../gcc/libcpp/line-map.c:566
0x133a050 linemap_position_for_column(line_maps*, unsigned int)
../../gcc/libcpp/line-map.c:611
0x1338131 _cpp_lex_direct
../../gcc/libcpp/lex.c:2329
0x133905d _cpp_lex_token
../../gcc/libcpp/lex.c:2166
0x133e007 cpp_get_token_1
../../gcc/libcpp/macro.c:2442
0x86168c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc/gcc/c-family/c-lex.c:408
0x70101f cp_lexer_get_preprocessor_token
../../gcc/gcc/cp/parser.c:779
0x737fae cp_lexer_new_main
../../gcc/gcc/cp/parser.c:660
0x737fae cp_parser_new
../../gcc/gcc/cp/parser.c:3484
0x737fae c_parse_file()
../../gcc/gcc/cp/parser.c:33190
0x869c12 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1057
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/63385] internal compiler error: in pop_binding, at cp/name-lookup.c for implicitly captured variable called closure

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Marek Polacek  ---
4.8/4.9/5 do not ICE anymore, closing as fixed thus.

[Bug c++/65552] New: [c++-concepts] Constraint checking regression for concepts with multiple type requirements

[tom at honermann dot net]

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

Bug ID: 65552
   Summary: [c++-concepts] Constraint checking regression for
concepts with multiple type requirements
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at honermann dot net

I built the latest revision of the gcc c++-concepts branch (r221648) last night
and encountered a regression in constraint checking for concepts that specify
multiple type requirements.

Constraint checking only fails if a requires expression specifies multiple type
requirements.  Placing the type constraints in distinct requires expressions
suffices to work around the problem.

$ cat t.cpp
template
concept bool Concept() {
return requires () {
   typename T::member_type1;
#if WORKAROUND
   }
&& requires () {
#endif
   typename T::member_type2;
   };
}
struct model {
using member_type1 = int;
using member_type2 = int;
};
template
struct S {};
S s;

$ svn info   # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221648
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221633
Last Changed Date: 2015-03-24 09:36:27 -0400 (Tue, 24 Mar 2015)

$ g++ -c -std=c++1z t.cpp
t.cpp:18:8: error: template constraint failure
 S s;
^
t.cpp:18:8: note:   constraints not satisfied
t.cpp:18:8: note:   concept ‘Concept()’ was not satisfied

$ g++ -c -std=c++1z t.cpp -DWORKAROUND

[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

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from ienkovich at gcc dot gnu.org ---
When instrumentation clone is created for a node with a comdat group, it gets
the same comdat group and is linked with the original node via
same_comdat_group. Do I need to change this behavior to pass verification (e.g.
don't set same_comdat_group for the clone in case the original node has NULL
for same_comdat_group and is not a function definition)?

Probably would be easier to just always have same_comdat_group list for nodes
with same comdat_group with no exceptions.

[Bug c++/61717] seg fault on using variadic templates to initialize array

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
4.8/4.9/5 do not ICE for me anymore.

[Bug c++/61639] GCC 4.7.4 can't longer compile clang

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-03-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Marek Polacek  ---
Without a testcase there's nothing to do.

[Bug c++/65553] New: ICE on valid variadic template

[webrown.cpp at gmail dot com]

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

Bug ID: 65553
   Summary: ICE on valid variadic template
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com

Created attachment 35134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35134&action=edit
program producing ICE

When compiling enclosed program via
  g++-mp-5 (MacPorts gcc5 5-20150308_0) 5.0.0 20150308 (experimental)
via command line
  g++-mp-5 -std=c++14 junk.cpp
the following messages obtain:

junk.cpp:10:38: internal compiler error: tree check: accessed elt 2 of tree_vec
with 1 elts in check_instantiated_args, at cp/pt.c:15822
 template< typename... Args, bool B = F2 >
  ^
junk.cpp:10:38: internal compiler error: Abort trap: 6
g++-mp-5: internal compiler error: Abort trap: 6 (program cc1plus)

Thanks to Andrew Sutton for reducing the test case.

[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).

[gang.chen.5i5j at gmail dot com]

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

--- Comment #3 from Chen Gang  ---
(In reply to Chen Gang from comment #2)
> For test.i:
> 
> int oxu_driver_init(void)
> {
>  *(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
> }
> 
> If test.i use a valid number (>= 0x10) or normal variable instead of "-1",
> it will be OK (the insns are almost the same between using valid numbers and
> using variable).
> 
> If test.i use 0 (NULL) instead of "-1", it will be OK, too, but it will
> generate an abort() insn for it (unlike valid numbers' and variable's insn).
> 
> If test.i se invalid number (e.g. -2, -1, 0x1, 0x2 ... 0xf), it will
> generate a different insn which can not be recognized by MD file.
> 
> 
> So for me, we need process the left invalid numbers just as processing 0
> (NULL) -- generate an abort() insn for them.

Oh, sorry, the contents above is incorrect, it is about memory alignment issue.
If the alignment is less than 32, it will cause issue. e.g. 0, 4, 8, 16, 20,
pointer parameter ... are all OK, but the other will cause issue.

[Bug libstdc++/33394] Add test case for Thread race segfault in std::string::append with -O and -s

[alalaw01 at gcc dot gnu.org]

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

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Wed Mar 25 15:46:58 2015
New Revision: 221666

URL: https://gcc.gnu.org/viewcvs?rev=221666&root=gcc&view=rev
Log:
PR libstdc++/33394
* testsuite/21_strings/basic_string/pthread33394.cc: Use
dg-additional-options.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/21_strings/basic_string/pthread33394.cc

[Bug c++/65553] ICE on valid variadic template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I can't reproduce.

[Bug middle-end/65554] New: [5 Regression] ICE: verify_gimple failed

[doko at gcc dot gnu.org]

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

Bug ID: 65554
   Summary: [5 Regression] ICE: verify_gimple failed
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

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

seen building openmsx in Debian unstable, with r221551, fails with -O[123],
works with -O0

g++ -MP -MMD -MF derived/x86_64-linux-debian/dep/ide/HDCommand.d -o
derived/x86_64-linux-debian/obj/ide/HDCommand.o -g -fstack-protector-strong
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O3 -m64 -pipe
-std=gnu++0x -Wall -Wextra -Wundef -Wunused-macros
-Wno-missing-field-initializers -Wzero-as-null-pointer-constant -Isrc
-Isrc/cassette -Isrc/commands -Isrc/config -Isrc/console -Isrc/cpu
-Isrc/debugger -Isrc/events -Isrc/fdc -Isrc/file -Isrc/ide -Isrc/input
-Isrc/laserdisc -Isrc/memory -Isrc/security -Isrc/serial -Isrc/settings
-Isrc/sound -Isrc/thread -Isrc/utils -Isrc/video -Isrc/video/ld
-Isrc/video/scalers -Isrc/video/v9990 -Iderived/x86_64-linux-debian/config
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL
-D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/freetype2 -I/usr/include/libpng12
-I/usr/include/tcl8.5 -I/usr/include/libxml2 -c src/ide/HDCommand.cc
src/ide/HDCommand.cc: In member function 'virtual void
openmsx::HDCommand::tabCompletion(std::vector >&)
const':
src/ide/HDCommand.cc:78:6: error: non-trivial conversion at assignment
 void HDCommand::tabCompletion(vector& tokens) const
  ^
long unsigned int
const char[7] *
# .MEM_152 = VDEF <.MEM_149>
MEM[(char * {ref-all})_88] = _126;
src/ide/HDCommand.cc:78:6: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/65553] ICE on valid variadic template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Seconded. We can't take action with this testcase, sorry.

[Bug middle-end/65555] New: [5 Regression] ICE: verify_gimple failed (LHS in noreturn call)

[doko at gcc dot gnu.org]

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

Bug ID: 6
   Summary: [5 Regression] ICE: verify_gimple failed (LHS in
noreturn call)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

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

seen building the poligraph package in Debian unstable, using r221551

$ g++ -c -g -O src/xstd/FileScanner.ii 
FileScanner.cc: In member function 'void FileScanner::configure(int)':
FileScanner.cc:331:1: error: LHS in noreturn call
# VUSE <.MEM_51>
_20 = xexit (_22);
FileScanner.cc:331:1: internal compiler error: verify_gimple failed
Please submit a full bug report,

[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Mar 25 16:01:36 2015
New Revision: 221667

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

PR bootstrap/65537
* bootstrap-lto-noplugin.mk: New build configuration.

gcc/ChangeLog:

PR bootstrap/65537
* doc/install.texi (Building a native compiler): Document new
bootstrap-lto-noplugin configuration.  Mention that bootstrap-lto
configuration assumes that the host supports the linker plugin.


Added:
trunk/config/bootstrap-lto-noplugin.mk
Modified:
trunk/config/ChangeLog
trunk/gcc/ChangeLog
trunk/gcc/doc/install.texi

[Bug c++/57588] [C++11] static constexpr in class fails to link

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #8 from Paolo Carlini  ---
Thus, if I understand correctly the discussion (otherwise, please, reopen!)
modulo access control issues in the testcase, we correctly fail at linktime.

[Bug middle-end/65556] New: [5 Regression] ICE: verify_gimple failed (type precision mismatch in switch statement)

[doko at gcc dot gnu.org]

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

Bug ID: 65556
   Summary: [5 Regression] ICE: verify_gimple failed (type
precision mismatch in switch statement)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

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

seen building the pcf2bdf package in Debian unstable, using r221551

$ g++ -c -g -O2 -Wno-write-strings pcf2bdf.ii 
pcf2bdf.cc: In function 'int main(int, char**)':
pcf2bdf.cc:559:5: error: type precision mismatch in switch statement
 int main(int argc, char *argv[])
 ^
switch (D.5231) , case 0: , case 1: >
pcf2bdf.cc:559:5: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/30277] bit-field: wrong overload resolution

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC|gcc-bugs at gcc dot gnu.org|
 Ever confirmed|0   |1

[Bug ipa/65557] New: ICE: SIGSEGV in hash_table<>::find_slot_with_hash() with -fdevirtualize -fipa-cp -fipa-icf-functions

[zsojka at seznam dot cz]

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

Bug ID: 65557
   Summary: ICE: SIGSEGV in hash_table<>::find_slot_with_hash()
with -fdevirtualize -fipa-cp -fipa-icf-functions
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

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

Compiler output:
$ gcc -fdevirtualize -fipa-cp -fipa-icf-functions testcase.C 
testcase.C:16:6: internal compiler error: Segmentation fault
 S1 s1;
  ^
0xe0a5cf crash_signal
/mnt/svn/gcc-trunk/gcc/toplev.c:383
0xc123e2 hash_table::summary_hashmap_traits>::hash_entry,
xcallocator, true>::find_slot_with_hash(int const&, unsigned int,
insert_option)
/mnt/svn/gcc-trunk/gcc/hash-table.h:1542
0xc12591 hash_map::summary_hashmap_traits>::get_or_insert(int
const&, bool*)
/mnt/svn/gcc-trunk/gcc/hash-map.h:232
0xc12591 function_summary::get(int)
/mnt/svn/gcc-trunk/gcc/symbol-summary.h:230
0x18605de function_summary::get(cgraph_node*)
/mnt/svn/gcc-trunk/gcc/symbol-summary.h:112
0x18605de ipa_icf::sem_function::equals_wpa(ipa_icf::sem_item*,
hash_map&)
/mnt/svn/gcc-trunk/gcc/ipa-icf.c:518
0x18581ca ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool)
/mnt/svn/gcc-trunk/gcc/ipa-icf.c:2518
0x185fb7a ipa_icf::sem_item_optimizer::execute()
/mnt/svn/gcc-trunk/gcc/ipa-icf.c:2296
0x18624a6 ipa_icf_driver
/mnt/svn/gcc-trunk/gcc/ipa-icf.c:3172
0x18624a6 ipa_icf::pass_ipa_icf::execute(function*)
/mnt/svn/gcc-trunk/gcc/ipa-icf.c:3219
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r221607 - ICE

[Bug c++/50462] poor diagnostics for missing parenthesis in call to method

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
By the way, now clang does much better.

[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-25
 CC||vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from vries at gcc dot gnu.org ---
I see the same failure on arm-linux-gnueabihf.

[Bug c++/65558] New: crash using __attribute__((__abi_tag__)) on anonymous inline namespace

[trippels at gcc dot gnu.org]

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

Bug ID: 65558
   Summary: crash using __attribute__((__abi_tag__)) on anonymous
inline namespace
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org

markus@x4 tmp % cat n.ii
inline namespace __attribute__((__abi_tag__)) {}

markus@x4 tmp % g++ -c n.ii
n.ii:1:47: internal compiler error: Segmentation fault
 inline namespace __attribute__((__abi_tag__)) {}
   ^
0xcaf40f crash_signal
../../gcc/gcc/toplev.c:383
0x7daa72 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:2845
0x7daa72 handle_namespace_attrs(tree_node*, tree_node*)
../../gcc/gcc/cp/name-lookup.c:3670
0x73867c cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:16247
0x737c69 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11366
0x737dfa cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11264
0x73810f cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4100
0x73810f c_parse_file()
../../gcc/gcc/cp/parser.c:33193
0x869c12 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1057
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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